By the way this all runs cleanly on Windows using the Windows python and either Windows compilers or the Windows port of the gcc compilers.
It also runs cleanly under cygwin (ignoring cygwins rebase, resource issues bugs). Barry On Mar 10, 2011, at 9:36 AM, Barry Smith wrote: > > On Mar 10, 2011, at 9:01 AM, Satish Balay wrote: > >> python and win32fe are both cygwin dependencies and they are >> interlinked with cygwin PATHS, and UNIX style compiler usage. >> >> Barry started to make fixes to configure to not use cygwin-python. But >> I think the critical thing would be replacing win32fe functionality in >> python - and making sure all python code that deals with >> compilers/flags don't have UNIXISM in them... > > I got so frustrated with the many levels of python crap to compile/test > anything in BuildSystem (for example compilers.py, setCompilers.py > compile/Processor.py and compile/XXX.py compilerFlags.py and > compilerOptions.py and the fact that every level is totally UNIX style and > unix assumptions* that I decided it was hopeless and stopped mucking with the > BuildSystem code to fix it to work properly on Windows > > * here is just one example of the millions of unix assumptions. You assume to > indicate an output file from a compiler (for example) is done with FLAG SPACE > FILENAME and that SPACE is hardwired in the python code. Now in Windows > sometimes the model is FLAGFILENAME (no space no nothing between the > indicating flag and the FILENAME) fixing this means tons of fucking around > with the current python code. > > To see how difficult it would be to unify the unix/windows compile model I > started something new from scratch with the goal of simple clean code and not > ten levels of function calls that was written from day one to respect all the > crazy ways unix does things and the even crazier ways Windows compilers do > things. It required little code and can be found at ssh://petsc at > petsc.cs.iit.edu//hg/petsc/cll cll stands for compiler, librarier and linker > (the three things the build system needs to communicate with the development > system). I instantiated the classes for C, C++, Fortran, Java, CUDA, > Matlab's mex, and cython (a big problem with BuildSystem is that it didn't > cover enough languages/paradgms to get general enough abstractions, shared > libraries, dynamic libraries, I even added the flag testing/compiler options > checking and generation of the list of library dependencies directly into > the various language classes. It was fun and could potentially replace a huge > chunk of BuildSystem code with a much smaller chunk. But then I realized > there was no easy way to merge such a beasty into BuildSystem and adding all > the other stuff that BuildSystem does to it was too much work so I stopped > work on it. > > Basically it is an attempt to totally refactor BuildSystem using everything > that was learned in the development of BuildSystem; it has no new ideas that > are not in BuildSystem it is just much simplier because all the paradgms are > already understood when I wrote it. > > It has been sitting ignored for several months. > > Barry > > As evidenced from PETSc my model is (1) very few classes (2) proper names for > classes so people immediately what is a subclass of another class, for > example the compiler class is called Compiler, the compiler class for Mex is > CompilerMex(), the method you call on the Compiler class to compile something > is compile(). > > To me the biggest flaw in almost all object oriented languages is that you > can name a subclass any fucking thing you want without regard to the classes > it is derived off of. With this model how the hell can someone keep track of > what a class is related to? For example in pseudo language "class joe derived > from adumbname" and class astupidname derived from joe". So I come upon > astupidname in code I have no clue how it is related to joe if the names HAD > to be linked then it would be something like "class > adumpname_joe_astupidname" and I would immediately know the relationship. Now > you could argue developers could just impose this requirement but they NEVER > DO! Well I do. > > > > > >> >> satish >> >> On Thu, 10 Mar 2011, Matthew Knepley wrote: >> >>> If we use all Python to build on Windows, with win32fe and the Windows >>> compilers, what >>> dependencies on Cygwin do we have left? >>> >>> Thanks, >>> >>> Matt >>> >>> >> >
