Fwd: [PETSC #18705] PETSc and Cygwin License (POSIX layer)
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 bsm...@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
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20081204/55dc7a43/attachment.html
Fwd: [PETSC #18705] PETSc and Cygwin License (POSIX layer)
On Thu, 4 Dec 2008, 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).
For one there is some cygwin code in win32fe to handle cygwin paths
[its difficult for us avoid doing this - and solely rely on MS path
scheme in our builds].
And I don't think its an issue of 'make clone'. We use tons of shell
and other unixy stuff in the build process - within each recursive
make invocation steps.
Satish
Fwd: [PETSC #18705] PETSc and Cygwin License (POSIX layer)
On Thu, Dec 4, 2008 at 12:41 PM, Satish Balay balay at mcs.anl.gov wrote:
On Thu, 4 Dec 2008, 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).
For one there is some cygwin code in win32fe to handle cygwin paths
[its difficult for us avoid doing this - and solely rely on MS path
scheme in our builds].
Did not know that. It will have to be rewritten.
And I don't think its an issue of 'make clone'. We use tons of shell
and other unixy stuff in the build process - within each recursive
make invocation steps.
We have slowly eliminated the use of UNIX tools from the build. I believe
the last impediment is shell. All this shell code would be converted to
Python, since our 'make clone' would speak Python natively instead of shell.
The March of Progress.
Matt
Satish
--
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/20081204/d7fb3db5/attachment.html
[PETSC #18705] PETSc and Cygwin License (POSIX layer)
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.
For instance, almost everything comes down to a compile, link, or execution.
I will now say toolbox, or maybe
toolbag (buildstuff?).
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
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20081204/2f6defad/attachment.html
[PETSC #18705] PETSc and Cygwin License (POSIX layer)
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
[PETSC #18705] PETSc and Cygwin License (POSIX layer)
On Thu, Dec 4, 2008 at 4:42 PM, Barry Smith bsmith at mcs.anl.gov wrote:
Make is NOT the problem! (It is just one of several)
Indeed. However, at some time I'll try to make PETSc build with Scons.
But we need to fix configure first.
Config/configure.py uses the SHELL constantly for basically everything. Try
running config/configure.py
under Windows without using cygwin.
I tried at home to run it with standard Windows's Python and
MinGW+MSYS, but I had no success up to now (however, I have not tried
hard)
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
--
Lisandro Dalc?n
---
Centro Internacional de M?todos Computacionales en Ingenier?a (CIMEC)
Instituto de Desarrollo Tecnol?gico para la Industria Qu?mica (INTEC)
Consejo Nacional de Investigaciones Cient?ficas y T?cnicas (CONICET)
PTLC - G?emes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594
[PETSC #18705] PETSc and Cygwin License (POSIX layer)
Hi all,
I am really glad to hear this. This is exactly what I wished, and told you some
time ago.
Just wanted you to know that there is a Windows Services For Unix (SFU)
add-on for Windows, which is in some way like Cygwin. It is free, and can be
downloaded by everyone. It has support for unix paths, too. I really do not
like it (even as much as Cygwin), but it can be somewhat useful for you /
someone else, if you take a look at it:
http://technet.microsoft.com/en-us/interopmigration/bb380242.aspx
Best regards,
Farshid Mossaiby
--- On Thu, 12/4/08, Lisandro Dalcin dalcinl at gmail.com wrote:
From: Lisandro Dalcin dalcinl at gmail.com
Subject: Re: [PETSC #18705] PETSc and Cygwin License (POSIX layer)
To: petsc-dev at mcs.anl.gov
Date: Thursday, December 4, 2008, 10:28 PM
On Thu, Dec 4, 2008 at 4:42 PM, Barry Smith
bsmith at mcs.anl.gov wrote:
Make is NOT the problem! (It is just one of several)
Indeed. However, at some time I'll try to make PETSc
build with Scons.
But we need to fix configure first.
Config/configure.py uses the SHELL constantly for
basically everything. Try
running config/configure.py
under Windows without using cygwin.
I tried at home to run it with standard Windows's
Python and
MinGW+MSYS, but I had no success up to now (however, I have
not tried
hard)
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
--
Lisandro Dalc?n
---
Centro Internacional de M?todos Computacionales en
Ingenier?a (CIMEC)
Instituto de Desarrollo Tecnol?gico para la Industria
Qu?mica (INTEC)
Consejo Nacional de Investigaciones Cient?ficas y
T?cnicas (CONICET)
PTLC - G?emes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594
[PETSC #18705] PETSc and Cygwin License (POSIX layer)
On Thu, 4 Dec 2008, Farshid Mossaiby wrote: Hi all, I am really glad to hear this. This is exactly what I wished, and told you some time ago. Just wanted you to know that there is a Windows Services For Unix (SFU) add-on for Windows, which is in some way like Cygwin. It is free, and can be downloaded by everyone. It has support for unix paths, too. I really do not like it (even as much as Cygwin), but it can be somewhat useful for you / someone else, if you take a look at it: This is no good for us. Last I checked we can't invoke MS compiler from this posix subsystem - or create native MS binaries from it.. i.e all binaries created in this susbsystem [perhaps with gcc] have to be run within the subsystem.. Satish http://technet.microsoft.com/en-us/interopmigration/bb380242.aspx Best regards, Farshid Mossaiby
[PETSC #18705] PETSc and Cygwin License (POSIX layer)
On Thu 2008-12-04 16:58, Lisandro Dalcin wrote: On Thu, Dec 4, 2008 at 4:42 PM, Barry Smith bsmith at mcs.anl.gov wrote: Make is NOT the problem! (It is just one of several) Indeed. However, at some time I'll try to make PETSc build with Scons. Presumably you have some experience with SCons, but I think it's really not such a good way to go. It's pretty slow for large projects and the caching design seems to generate inconsistent state somewhat regularly. Also, big projects seem to always end up with a fork of SCons or abandon it for alternatives. I've been using CMake for my stuff (linking against PETSc and a few other libs). The syntax is pretty hideous for scripting, but the declarative build definition is very nice. Since it uses the native build system, the IDE-using people on Windows would probably prefer it as well. It would be trivial (like an hour, plus some for tests) to replace the current recursive make with CMake, replacing BuildSystem would obviously require a bit of tedium, if it was even desirable. BuildSystem is a very different beast from the configuration tools that are out there since it also fills in as a package manager (extremely nice since lots of optional dependencies have really painful build systems). In any case, having proper dependency analysis would be *really* cool, a do-nothing rebuild of ParaView (includes VTK, 2M LOC in many directories) takes 10 seconds so the usual PETSc few-file recompile after 'hg pull -u' would be a 2-second affair. Anyway, I'd suggest having a look at CMake before implementing an SCons build. Jed -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20081204/a06a6165/attachment.pgp
[PETSC #18705] PETSc and Cygwin License (POSIX layer)
Hi, I do not know related it is, boost_build / bjam is another beast to consider. Based on python, runs OK on windows and seem quite nice in the project I work with it. Regards, Farshid Mossaiby --- On Fri, 12/5/08, Jed Brown jed at 59A2.org wrote: From: Jed Brown jed at 59A2.org Subject: Re: [PETSC #18705] PETSc and Cygwin License (POSIX layer) To: petsc-dev at mcs.anl.gov Date: Friday, December 5, 2008, 12:21 AM On Thu 2008-12-04 16:58, Lisandro Dalcin wrote: On Thu, Dec 4, 2008 at 4:42 PM, Barry Smith bsmith at mcs.anl.gov wrote: Make is NOT the problem! (It is just one of several) Indeed. However, at some time I'll try to make PETSc build with Scons. Presumably you have some experience with SCons, but I think it's really not such a good way to go. It's pretty slow for large projects and the caching design seems to generate inconsistent state somewhat regularly. Also, big projects seem to always end up with a fork of SCons or abandon it for alternatives. I've been using CMake for my stuff (linking against PETSc and a few other libs). The syntax is pretty hideous for scripting, but the declarative build definition is very nice. Since it uses the native build system, the IDE-using people on Windows would probably prefer it as well. It would be trivial (like an hour, plus some for tests) to replace the current recursive make with CMake, replacing BuildSystem would obviously require a bit of tedium, if it was even desirable. BuildSystem is a very different beast from the configuration tools that are out there since it also fills in as a package manager (extremely nice since lots of optional dependencies have really painful build systems). In any case, having proper dependency analysis would be *really* cool, a do-nothing rebuild of ParaView (includes VTK, 2M LOC in many directories) takes 10 seconds so the usual PETSc few-file recompile after 'hg pull -u' would be a 2-second affair. Anyway, I'd suggest having a look at CMake before implementing an SCons build. Jed
