[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 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)
On Thu, Dec 4, 2008 at 4:42 PM, Barry Smith 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
>> Date: Thu, Dec 4, 2008 at 12:00 PM
>> Subject: Re: [PETSC #18705] PETSc and Cygwin License (POSIX layer)
>> To: Stefan Benkler
>> 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
Who has the download info?
Whatever is a convenient number at the time you need to "annouce it" :-) I don't see any good way to get a handle on it. Number of downloads is a garbage number (likely a huge overestimate). Number of unique people who send us email is likely underestimate. I just modestly say in the hundreds. (Though in one form or another it is over 1000). Barry On Dec 4, 2008, at 3:47 PM, Matthew Knepley wrote: > What are we announcing as the number of "PETSc Users"? > > 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
Who has the download info?
What are we announcing as the number of "PETSc Users"? 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/20081204/c8dab834/attachment.html>
[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 wrote: > From: Jed Brown > 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 > 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
[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 Dec 4, 2008, at 12:51 PM, Matthew Knepley wrote:
> On Thu, Dec 4, 2008 at 12:42 PM, Barry Smith
> 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
> Date: Thu, Dec 4, 2008 at 12:00 PM
> Subject: Re: [PETSC #18705] PETSc and Cygwin License (POSIX layer)
> To: Stefan Benkler
> 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 12:42 PM, Barry Smith 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
>> Date: Thu, Dec 4, 2008 at 12:00 PM
>> Subject: Re: [PETSC #18705] PETSc and Cygwin License (POSIX layer)
>> To: Stefan Benkler
>> 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>
Fwd: [PETSC #18705] PETSc and Cygwin License (POSIX layer)
On Thu, Dec 4, 2008 at 12:41 PM, Satish Balay 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)
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 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
> Date: Thu, Dec 4, 2008 at 12:00 PM
> Subject: Re: [PETSC #18705] PETSc and Cygwin License (POSIX layer)
> To: Stefan Benkler
> 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
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)
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
Date: Thu, Dec 4, 2008 at 12:00 PM
Subject: Re: [PETSC #18705] PETSc and Cygwin License (POSIX layer)
To: Stefan Benkler
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>
[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 wrote:
> From: Lisandro Dalcin
> 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
> 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
> >> Date: Thu, Dec 4, 2008 at 12:00 PM
> >> Subject: Re: [PETSC #18705] PETSc and Cygwin
> License (POSIX layer)
> >> To: Stefan Benkler
> >> 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?fic
