[petsc-dev] All Python Windows build

[Barry Smith]

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@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
>> 
>> 
>