[petsc-dev] All Python Windows build

[Matthew Knepley]

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>