On Thu, Mar 10, 2011 at 9:36 AM, Barry Smith <bsmith at mcs.anl.gov> 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 > I guess I object to the characterization of this as completely hopeless. I do not even think its that complicated. We have a base class Processor, that runs one of these guys. Then subclasses for each preprocessor/compiler/linker in a module named for the language. I will look at cll. Matt > * 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 > >> > >> > > > > -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20110310/5173d9e0/attachment.html>
