On Dec 4, 2008, at 12:51 PM, Matthew Knepley wrote: > On Thu, Dec 4, 2008 at 12:42 PM, Barry Smith <bsmith at mcs.anl.gov> > wrote: > > Make is NOT the problem! (It is just one of several) > > Config/configure.py uses the SHELL constantly for basically > everything. Try running config/configure.py > under Windows without using cygwin. > > I disagree with this characterization. The lowest level definitely > spawns shell jobs, however at the configure > level, they are a small set of specific tasks, and it would not be > hard to retarget them to a different architecture.
That just has to be done. > > For instance, almost everything comes down to a compile, link, or > execution. I will now say "toolbox", or maybe > "toolbag" (buildstuff?). In the HPC, world the most accurate term is "bunch of crappy software I use". Barry > > > Matt > > > I hate the term "toolchain" > > > Barry > > > On Dec 4, 2008, at 12:04 PM, Matthew Knepley wrote: > > I for one think it should be possible to remove 'make' from the > toolchain, leaving us with only win32fe, which we distribute. Thus > I think we could abandon cygwin once and for all. I would even be > willing to write a \emph{make clone} to accomplish this, even though > I am a committed enemy of make (which once TP'ed my house). > > Matt > > ---------- Forwarded message ---------- > From: Barry Smith <bsmith at mcs.anl.gov> > Date: Thu, Dec 4, 2008 at 12:00 PM > Subject: Re: [PETSC #18705] PETSc and Cygwin License (POSIX layer) > To: Stefan Benkler <benkler at itis.ethz.ch> > Cc: petsc-maint at mcs.anl.gov > > > Stefan, > > Here is my understanding of the situation. > > Conjecture: You CAN use an open source compiler (GNU) to compile > proprietary code and then sell > the binaries without making the proprietary code GNU licensed so > long as you just use the > GNU compilers out of the box and don't change their source code and > don't include the compliers > libraries in your binaries. > > IF this is true then you are safe, the Cygwin environment is only > used by PETSc to have > a system to compile PETSc. None of it is included in the binaries > generated. > > On the other hand, if my initial conjecture is wrong, then there > could be a problem. > > Barry > > We've tried over the years to use Windows "posix" environments to > develop a build system > for PETSc so we don't need cygwin to build PETSc. Unfortunately > their stuff is so "un-unix" > like that it just wasn't practical and using developers studio to > build PETSc directly is > possible but requires some how getting all the PETSc source properly > into developers studio > and as far as I know the only way to do this is manually through the > gui which is very painful; > plus if we change something in the Unix build side later we'd need > to change it manually > on the developers studio side. > > If the situation has changed and Windows does provide a reasonable > way to build large > unix codes I'd love to hear about it and use it. We hate cygwin but > feel with have no other > reasonable option. > > On Dec 4, 2008, at 3:33 AM, Stefan Benkler wrote: > > Dear PETSc developers > > Since a while, I successfully use your fantastic library on Windows. > Thank you very much! > > Lately, I had a discussion about the involved copyrights/licenses > with a colleague. The main point was if PETSc requires the POSIX > layer of cygwin on Windows (and therefore would need to fulfill > cygwin's GPL license). > > My standpoint was that cygwin is just used to configure and build > the library, but only native Windows libraries (using MS or Intel's > Windows compiler, MKL) are finally linked to the PETSc libs. > However, I have difficulties to proof this claim, which is the > reason for this email. > > Please comment/clarify the licensing on a Windows system. > > Thanks a lot for your informations. > > Best regards > > Stefan Benkler > > > > > > > -- > 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 > > > > > -- > 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