10:35 a.m.
Hi
LLVM 2.6 has been announced with Clang declared as production quality in
this release
http://lists.cs.uiuc.edu/pipermail/llvm-announce/2009-October/000033.html
Has anyone been looking into building Fedora with it to see how the
performance impact is?
Rahul
12:21 p.m.
Rahul Sundaram wrote:
LLVM 2.6 has been announced with Clang declared as production quality
in
this release
http://lists.cs.uiuc.edu/pipermail/llvm-announce/2009-October/000033.html
Has anyone been looking into building Fedora with it to see how the
performance impact is?
A lot of upstream software on GNU/Linux only supports GCC. Clang tries to
support GCC extensions, but I strongly doubt it'll compile all upstream code
unchanged, and upstream projects might even reject patches to fix the build
with Clang because they only support GCC.
Kevin Kofler
12:35 p.m.
On Sun, Oct 25, 2009 at 12:21 PM, Kevin Kofler <kevin.kofler(a)chello.at>wrote:
Rahul Sundaram wrote:
> LLVM 2.6 has been announced with Clang declared as production quality in
> this release
>
>
http://lists.cs.uiuc.edu/pipermail/llvm-announce/2009-October/000033.html
>
> Has anyone been looking into building Fedora with it to see how the
> performance impact is?
A lot of upstream software on GNU/Linux only supports GCC. Clang tries to
support GCC extensions, but I strongly doubt it'll compile all upstream
code
unchanged, and upstream projects might even reject patches to fix the build
with Clang because they only support GCC.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Also, clang's support with C++ ABI is still very broken. It's listed under
known issues. While most applications are made with C or Python, there are
still a fair number of C++ applications...
4:52 p.m.
King InuYasha wrote:
Also, clang's support with C++ ABI is still very broken. It's
listed under
known issues.
Actually, the ABI issue is only if you use the C code generator, not the
native ones.
The real problem is that C++ support in Clang is just not complete. You may
have more luck with llvm-g++, but that one always has trouble keeping up
with current GCC and it probably doesn't bring all that many benefits over
just using GCC.
While most applications are made with C or Python, there are still a
fair
number of C++ applications...
(Nearly) all of KDE is C++!
Kevin Kofler
10:40 p.m.
On Sun, Oct 25, 2009 at 5:52 PM, Kevin Kofler <kevin.kofler(a)chello.at> wrote:
Actually, the ABI issue is only if you use the C code generator, not
the
native ones.
I'm not sure I understand. How can LLVM-C be ABI-incompatible with plain GCC-C?
I thought that C doesn't have any crazy name or symbol or virtual
table mangling. The stuff should just work, right?
Does that mean that I can't write a GTK program and compile with
LLVM-C, since I can't link to the GTK libraries?
11:31 a.m.
Jud Craft wrote:
I'm not sure I understand. How can LLVM-C be ABI-incompatible
with plain
GCC-C?
It's the ABI of:
llvm-g++ → LLVM → LLVM C backend → gcc
or:
Clang (C++) → LLVM → LLVM C backend → gcc
which is incompatible with the ABI of plain g++.
AFAICT, the native LLVM backends don't have that problem. The real problem
with C++ is that Clang's C++ support is experimental and incomplete, so
you're stuck with llvm-g++.
I thought that C doesn't have any crazy name or symbol or
virtual
table mangling. The stuff should just work, right?
But this is about C++.
Kevin Kofler
5:30 p.m.
On Mon, Oct 26, 2009 at 12:31 PM, Kevin Kofler wrote:
AFAICT, the native LLVM backends don't have that problem. The real problem
with C++ is that Clang's C++ support is experimental and incomplete, so
you're stuck with llvm-g++.
> I thought that C doesn't have any crazy name or symbol or virtual
> table mangling. The stuff should just work, right?
But this is about C++.
I don't mean to misunderstand, but if I recall from your very first
post in this thread...
Actually, the ABI issue is only if you use the C code generator, not
the
native ones.
Hence I thought you were talking about ABI issues with C.
I'm not up on how LLVM frontend integration works, so I actually don't
understand the distinction between "the LLVM C Backend" and "the
native LLVM backends".
Simply, can I write and compile a GTK program with LLVM?
I'd love to use it for the intuitive error reporting, honestly.
2:05 a.m.
Le 26/10/2009 23:30, Jud Craft a écrit :
Hence I thought you were talking about ABI issues with C.
I'm not up on how LLVM frontend integration works, so I actually don't
understand the distinction between "the LLVM C Backend" and "the
native LLVM backends".
Simply, can I write and compile a GTK program with LLVM?
I'd love to use it for the intuitive error reporting, honestly.
the static analyzer works also with gcc, check scan-build.
H.
5:24 a.m.
Jud Craft wrote:
On Mon, Oct 26, 2009 at 12:31 PM, Kevin Kofler wrote:
> But this is about C++.
I don't mean to misunderstand, but if I recall from your very first
post in this thread...
> Actually, the ABI issue is only if you use the C code generator, not the
> native ones.
Hence I thought you were talking about ABI issues with C.
You misunderstood me. The C code generator is an LLVM *back*end, not a
frontend. The frontend is what recognizes the input language, the backend is
what defines the output LLVM generates.
I'm not up on how LLVM frontend integration works, so I actually
don't
understand the distinction between "the LLVM C Backend" and "the
native LLVM backends".
LLVM can either directly output machine code (native backend) for some
architectures or it can output preoptimized C code (especially for those
architectures which don't have a native backend). The latter is what the "C
code generator" or "C backend" does.
The ABI issues are when using one of the C++ frontends with the C backend.
Simply, can I write and compile a GTK program with LLVM?
Yes.
Kevin Kofler
6:44 a.m.
On 10/28/2009 06:24 AM, Kevin Kofler wrote:
Jud Craft wrote:
> On Mon, Oct 26, 2009 at 12:31 PM, Kevin Kofler wrote:
>> But this is about C++.
>
> I don't mean to misunderstand, but if I recall from your very first
> post in this thread...
>
>> Actually, the ABI issue is only if you use the C code generator, not the
>> native ones.
>
> Hence I thought you were talking about ABI issues with C.
You misunderstood me. The C code generator is an LLVM *back*end, not a
frontend. The frontend is what recognizes the input language, the backend is
what defines the output LLVM generates.
> I'm not up on how LLVM frontend integration works, so I actually don't
> understand the distinction between "the LLVM C Backend" and "the
> native LLVM backends".
LLVM can either directly output machine code (native backend) for some
architectures or it can output preoptimized C code (especially for those
architectures which don't have a native backend). The latter is what the "C
code generator" or "C backend" does.
clang and all other LLVM language front-ends produce "bitcode", which is
virtualized machine code a la JVM. LLVM backend generates
processor-dependent machine code from processor-independent machine code.
The LLVM C __backend__ converts bitcode back into C... something no
idiot in their right mind would use for C++ or anything else. The LLVM
C backend is not commonly used.
The vast, vast majority of people trying to compile C++ programs with
LLVM would either use
clang -> llvm -> asm code
or
llvm-gcc -> llvm -> asm code
Certainly not
Clang (C++) → LLVM → LLVM C backend → gcc [-> asm code]
Regards,
Jeff
12:38 p.m.
On 10/25/2009 10:51 PM, Kevin Kofler wrote:
Rahul Sundaram wrote:
> LLVM 2.6 has been announced with Clang declared as production quality in
> this release
>
> http://lists.cs.uiuc.edu/pipermail/llvm-announce/2009-October/000033.html
>
> Has anyone been looking into building Fedora with it to see how the
> performance impact is?
A lot of upstream software on GNU/Linux only supports GCC. Clang tries to
support GCC extensions, but I strongly doubt it'll compile all upstream code
unchanged, and upstream projects might even reject patches to fix the build
with Clang because they only support GCC.
We wouldn't know unless we try. Guess work doesn't lead to much. Hence
my question. Has anyone actually tried to do compile say a large C
codebase with LLVM?
Rahul
8:33 a.m.
On Sun, 2009-10-25 at 21:05 +0530, Rahul Sundaram wrote:
LLVM 2.6 has been announced with Clang declared as production quality
in
this release
http://lists.cs.uiuc.edu/pipermail/llvm-announce/2009-October/000033.html
Has anyone been looking into building Fedora with it to see how the
performance impact is?
I'm going to go out on a limb here and say that the dominating factor in
our performance is the code itself.
Also, last time I checked, llvm's dwarf support was even worse than
gcc's. No thanks.
- ajax
8:37 a.m.
On 10/26/2009 07:03 PM, Adam Jackson wrote:
On Sun, 2009-10-25 at 21:05 +0530, Rahul Sundaram wrote:
> LLVM 2.6 has been announced with Clang declared as production quality in
> this release
>
> http://lists.cs.uiuc.edu/pipermail/llvm-announce/2009-October/000033.html
>
> Has anyone been looking into building Fedora with it to see how the
> performance impact is?
I'm going to go out on a limb here and say that the dominating factor in
our performance is the code itself.
I meant performance, primarily in terms of speed of compilation. Not the
code itself.
Rahul
9:45 a.m.
On Mon, 2009-10-26 at 19:07 +0530, Rahul Sundaram wrote:
On 10/26/2009 07:03 PM, Adam Jackson wrote:
> On Sun, 2009-10-25 at 21:05 +0530, Rahul Sundaram wrote:
>> Has anyone been looking into building Fedora with it to see how the
>> performance impact is?
>
> I'm going to go out on a limb here and say that the dominating factor in
> our performance is the code itself.
I meant performance, primarily in terms of speed of compilation. Not the
code itself.
Suppose it's faster. Say even by a factor of 100. So what? What
problem would that solve?
- ajax
9:43 a.m.
On 10/26/2009 08:15 PM, Adam Jackson wrote:
On Mon, 2009-10-26 at 19:07 +0530, Rahul Sundaram wrote:
> On 10/26/2009 07:03 PM, Adam Jackson wrote:
>> On Sun, 2009-10-25 at 21:05 +0530, Rahul Sundaram wrote:
>>> Has anyone been looking into building Fedora with it to see how the
>>> performance impact is?
>>
>> I'm going to go out on a limb here and say that the dominating factor in
>> our performance is the code itself.
>
> I meant performance, primarily in terms of speed of compilation. Not the
> code itself.
Suppose it's faster. Say even by a factor of 100. So what? What
problem would that solve?
The problem of slow compilation? :-)
Rahul
9:51 a.m.
On Mon, 2009-10-26 at 20:13 +0530, Rahul Sundaram wrote:
On 10/26/2009 08:15 PM, Adam Jackson wrote:
> On Mon, 2009-10-26 at 19:07 +0530, Rahul Sundaram wrote:
>> On 10/26/2009 07:03 PM, Adam Jackson wrote:
>>> On Sun, 2009-10-25 at 21:05 +0530, Rahul Sundaram wrote:
>> I meant performance, primarily in terms of speed of compilation. Not the
>> code itself.
>
> Suppose it's faster. Say even by a factor of 100. So what? What
> problem would that solve?
The problem of slow compilation? :-)
Which affects who? koji certainly seems to be keeping up with the load.
What I'm trying to pry out of you is what you'd be hoping to accomplish
by using it. The answer so far seems to be "I'd spend less time
building things, at the cost of some unknown amount of time invested in
fixing everything to build again". That doesn't sound like progress.
- ajax
9:51 a.m.
On 10/26/2009 08:21 PM, Adam Jackson wrote:
Which affects who? koji certainly seems to be keeping up with the load.
What I'm trying to pry out of you is what you'd be hoping to accomplish
by using it. The answer so far seems to be "I'd spend less time
building things, at the cost of some unknown amount of time invested in
fixing everything to build again". That doesn't sound like progress.
Certainly status quo is easier. Less time building things is a obvious
benefit. We don't know the cost unless we try. Doing a scratch build
similar to the FTFBS rebuilds is definitely worth trying IMO. Arguing
that we should never try at all doesn't seem appealing to me.
Rahul
10:09 a.m.
On 10/26/2009 10:51 AM, Rahul Sundaram wrote:
On 10/26/2009 08:21 PM, Adam Jackson wrote:
>
> Which affects who? koji certainly seems to be keeping up with the load.
>
> What I'm trying to pry out of you is what you'd be hoping to accomplish
> by using it. The answer so far seems to be "I'd spend less time
> building things, at the cost of some unknown amount of time invested in
> fixing everything to build again". That doesn't sound like progress.
Certainly status quo is easier. Less time building things is a obvious
benefit.
This is just myopia, though. In isolation, yes, faster builds are nice. But
if the faster builds result in poorer quality, then no, they're not a benefit.
We don't know the cost unless we try. Doing a scratch build
similar to the FTFBS rebuilds is definitely worth trying IMO. Arguing
that we should never try at all doesn't seem appealing to me.
Go ahead and set that up. Report the result back to us.
--
Peter
Gravity is a habit that is hard to shake off.
-- Pratchett
10:07 a.m.
On 10/26/2009 08:39 PM, Peter Jones wrote:
This is just myopia, though. In isolation, yes, faster builds are
nice. But
if the faster builds result in poorer quality, then no, they're not a benefit.
Sure. Nobody claimed otherwise.
> We don't know the cost unless we try. Doing a scratch build
> similar to the FTFBS rebuilds is definitely worth trying IMO. Arguing
> that we should never try at all doesn't seem appealing to me.
Go ahead and set that up. Report the result back to us.
I was asking if anybody has already tried that. Don't understand the
argument against it yet.
Rahul
10:36 a.m.
On 10/26/2009 11:07 AM, Rahul Sundaram wrote:
On 10/26/2009 08:39 PM, Peter Jones wrote:
> This is just myopia, though. In isolation, yes, faster builds are nice. But
> if the faster builds result in poorer quality, then no, they're not a benefit.
Sure. Nobody claimed otherwise.
>> We don't know the cost unless we try. Doing a scratch build
>> similar to the FTFBS rebuilds is definitely worth trying IMO. Arguing
>> that we should never try at all doesn't seem appealing to me.
>
> Go ahead and set that up. Report the result back to us.
I was asking if anybody has already tried that. Don't understand the
argument against it yet.
If you had tried a project like this in the past, you would
understand the reasons against it.
If you do not understand those reasons from email, the only
cure would be to try it yourself. Then you will understand.
--
All rights reversed.
9:14 p.m.
On Mon, 2009-10-26 at 11:36 -0400, Rik van Riel wrote:
> I was asking if anybody has already tried that. Don't
understand the
> argument against it yet.
If you had tried a project like this in the past, you would
understand the reasons against it.
If you do not understand those reasons from email, the only
cure would be to try it yourself. Then you will understand.
As Rahul already said, multiple times, he was not asking people to give
him their valuable opinion on whether it was a good idea or not. He was
just asking if anyone else had already tried it.
Personally I find it a bit presumptuous of all the people who jumped in
to tell him what a terrible idea it would be, as if he were proposing
that we do it in the official repos and make everyone use it or
something. He just asked a simple question, there was no need to spray
stop energy all over the place.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
10:15 a.m.
On Mon, Oct 26, 2009 at 08:21:09PM +0530, Rahul Sundaram wrote:
On 10/26/2009 08:21 PM, Adam Jackson wrote:
>
> Which affects who? koji certainly seems to be keeping up with the load.
>
> What I'm trying to pry out of you is what you'd be hoping to accomplish
> by using it. The answer so far seems to be "I'd spend less time
> building things, at the cost of some unknown amount of time invested in
> fixing everything to build again". That doesn't sound like progress.
Certainly status quo is easier. Less time building things is a obvious
benefit. We don't know the cost unless we try. Doing a scratch build
similar to the FTFBS rebuilds is definitely worth trying IMO. Arguing
that we should never try at all doesn't seem appealing to me.
Sounds like something you should start trying then.
josh
10:15 a.m.
On Mon, 2009-10-26 at 20:21 +0530, Rahul Sundaram wrote:
On 10/26/2009 08:21 PM, Adam Jackson wrote:
> Which affects who? koji certainly seems to be keeping up with the load.
>
> What I'm trying to pry out of you is what you'd be hoping to accomplish
> by using it. The answer so far seems to be "I'd spend less time
> building things, at the cost of some unknown amount of time invested in
> fixing everything to build again". That doesn't sound like progress.
Certainly status quo is easier. Less time building things is a obvious
benefit. We don't know the cost unless we try. Doing a scratch build
similar to the FTFBS rebuilds is definitely worth trying IMO. Arguing
that we should never try at all doesn't seem appealing to me.
Please don't put words in my mouth, I did not say "never try at all". I
said that spending less time building things is only an obvious benefit
if we don't lose real functionality, and don't waste time placating the
compiler to get things to build.
But hey, if you're volunteering to run the experiment, go wild.
- ajax
10:22 a.m.
On 10/26/2009 08:45 PM, Adam Jackson wrote:
Please don't put words in my mouth, I did not say "never try at all". I
said that spending less time building things is only an obvious benefit
if we don't lose real functionality, and don't waste time placating the
compiler to get things to build.
Yes, I understand that. Note that benefit is not just speed. From a
earlier discussion,
http://www.linux-archive.org/fedora-development/362915-clang-static-analy...
But hey, if you're volunteering to run the experiment, go wild.
I am not volunteering. I just wanted to know if anyone else has already
tried it. If you read my original post, that's what I asked.
Rahul
10:37 a.m.
On 10/26/2009 11:22 AM, Rahul Sundaram wrote:
On 10/26/2009 08:45 PM, Adam Jackson wrote:
>
> Please don't put words in my mouth, I did not say "never try at all".
I
> said that spending less time building things is only an obvious benefit
> if we don't lose real functionality, and don't waste time placating the
> compiler to get things to build.
Yes, I understand that. Note that benefit is not just speed. From a
earlier discussion,
http://www.linux-archive.org/fedora-development/362915-clang-static-analy...
> But hey, if you're volunteering to run the experiment, go wild.
I am not volunteering. I just wanted to know if anyone else has already
tried it. If you read my original post, that's what I asked.
Well, why not?
--
Peter
Gravity is a habit that is hard to shake off.
-- Pratchett
10:37 a.m.
On 10/26/2009 09:07 PM, Peter Jones wrote:
Well, why not?
I am not curious enough to volunteer to do anything with it myself but
would be interested in hearing about the experiences of anyone who has
already done so. If you haven't, feel free to ignore my mail. Pretty
simple, really.
Rahul
9:54 a.m.
On 10/26/2009 10:51 AM, Adam Jackson wrote:
On Mon, 2009-10-26 at 20:13 +0530, Rahul Sundaram wrote:
> On 10/26/2009 08:15 PM, Adam Jackson wrote:
>> On Mon, 2009-10-26 at 19:07 +0530, Rahul Sundaram wrote:
>>> On 10/26/2009 07:03 PM, Adam Jackson wrote:
>>>> On Sun, 2009-10-25 at 21:05 +0530, Rahul Sundaram wrote:
>>> I meant performance, primarily in terms of speed of compilation. Not the
>>> code itself.
>>
>> Suppose it's faster. Say even by a factor of 100. So what? What
>> problem would that solve?
>
> The problem of slow compilation? :-)
Which affects who? koji certainly seems to be keeping up with the load.
What I'm trying to pry out of you is what you'd be hoping to accomplish
by using it. The answer so far seems to be "I'd spend less time
building things, at the cost of some unknown amount of time invested in
fixing everything to build again". That doesn't sound like progress.
Well, that plus your already voiced complaint about its dwarf generation,
which is to say that any fairly immediate adoption would also make normal
development and debugging more painful.
--
Peter
Gravity is a habit that is hard to shake off.
-- Pratchett
10:52 a.m.
On Mon, Oct 26, 2009 at 10:54:46AM -0400, Peter Jones wrote:
Well, that plus your already voiced complaint about its dwarf
generation,
which is to say that any fairly immediate adoption would also make normal
development and debugging more painful.
It is not just about horrible dwarf generation, the performance of LLVM
generated code is worse than GCC, you can forget about all the
security enhancements GCC has added in the last 10 years (say
__builtin_object_size is parsed by clang/llvm, but always says it doesn't
know the size, I'm not aware of LLVM supporting something like
-fstack-protector), etc. A lot of stuff is just stubbed in LLVM, look at
e.g. its __builtin_expect implementation. You need to look through the hype
at what disadvantages it has.
While there are places where compile time speed is most important (in some
JITing cases), the distro isn't one of those places.
Jakub
11:40 a.m.
Jakub Jelinek wrote:
It is not just about horrible dwarf generation, the performance of
LLVM
generated code is worse than GCC, you can forget about all the
security enhancements GCC has added in the last 10 years (say
__builtin_object_size is parsed by clang/llvm, but always says it doesn't
know the size, I'm not aware of LLVM supporting something like
-fstack-protector), etc. A lot of stuff is just stubbed in LLVM, look at
e.g. its __builtin_expect implementation. You need to look through the
hype at what disadvantages it has.
And I don't think that's going to change as long as LLVM stays BSD-licensed.
Most people are unwilling to contribute to a project of which proprietary
software companies can make "improved" proprietary versions of, which even
they as the original author aren't allowed to use without paying the
company, let alone modify or redistribute. Contributing to the GPLed GCC is
much more attractive. So LLVM is always going to lag behind in some areas.
Just look at how many contributions the Linux kernel gets vs. how many the
BSD kernels get.
Kevin Kofler
10:11 a.m.
On 10/26/2009 10:45 AM, Adam Jackson wrote:
On Mon, 2009-10-26 at 19:07 +0530, Rahul Sundaram wrote:
> On 10/26/2009 07:03 PM, Adam Jackson wrote:
>> On Sun, 2009-10-25 at 21:05 +0530, Rahul Sundaram wrote:
>>> Has anyone been looking into building Fedora with it to see how the
>>> performance impact is?
>>
>> I'm going to go out on a limb here and say that the dominating factor in
>> our performance is the code itself.
>
> I meant performance, primarily in terms of speed of compilation. Not the
> code itself.
Suppose it's faster. Say even by a factor of 100. So what? What
problem would that solve?
Personally I don't that compile speed is as interesting as new bugs the
compiler is able to highlight, either through the compilation process or
through the use of LLVM as a static analyzer.
But LLVM/clang is quite far away from building Fedora, so I do not think
there's a need for people to get anxious.
I worked for a couple weeks on fixing LLVM, clang and Linux kernel bugs
so that the kernel would build under clang.
Jeff
11:26 p.m.
On Mon, Oct 26, 2009 at 1:35 AM, Rahul Sundaram
<sundaram(a)fedoraproject.org> wrote:
Has anyone been looking into building Fedora with it to see how the
performance impact is?
I built about 5 or 6 of the C programs from
http://shootout.alioth.debian.org/ with clang and gcc, and
unfortunately (or perhaps fortunately) all the gcc programs ran
faster. Perhaps in a source distro you'd have different priorityies
but for Fedora I think the compile-time / run-time trade off is
clearly worth it.
As for C++, I couldn't get some of my programs to compile as it seemed
to spew at some of the template usage. Anyway it looks very promising
and I look forward to using it in the future (especially with its
non-nonsense licensing).
Also I'm sure the freebsd folks would have a tonne of insight to offer
( http://wiki.freebsd.org/BuildingFreeBSDWithClang )
5:26 a.m.
Eric Springer wrote:
As for C++, I couldn't get some of my programs to compile as it
seemed
to spew at some of the template usage. Anyway it looks very promising
and I look forward to using it in the future (especially with its
non-nonsense licensing).
So you don't consider it "nonsense" to allow proprietary software companies
to steal all your code without giving anything back? They can even sell you
back some trivially modified version of YOUR OWN code! Non-copyleft licenses
suck.
Kevin Kofler
6:35 a.m.
On Wed, Oct 28, 2009 at 11:26:54AM +0100, Kevin Kofler wrote:
Eric Springer wrote:
> As for C++, I couldn't get some of my programs to compile as it seemed
> to spew at some of the template usage. Anyway it looks very promising
> and I look forward to using it in the future (especially with its
> non-nonsense licensing).
So you don't consider it "nonsense" to allow proprietary software companies
to steal all your code without giving anything back? They can even sell you
back some trivially modified version of YOUR OWN code! Non-copyleft licenses
suck.
It's not stealing if you licensed it that way. Please avoid inflammatory
language.
josh
5:45 p.m.
On Wed, Oct 28, 2009 at 8:26 PM, Kevin Kofler <kevin.kofler(a)chello.at> wrote:
So you don't consider it "nonsense" to allow
proprietary software companies
to steal all your code without giving anything back?
When I write (opensource) code, I hope it's as useful to as many
people as possible. I'm not expecting recognition or payment or trying
to pushing any agenda, so I prefer to give without string attached.
Of course if it's your code, please do what ever you see fit . The
"nonsense" comment was more about all the compliance stuff required
when dealing with GPL software in propreitary projects
They can even sell you
back some trivially modified version of YOUR OWN code!
It'd be a hard sell!
5295
days inactive
5298
days old
34 comments
14 participants
participants (14)
-
Adam Jackson -
Adam Williamson -
Eric Springer -
Haïkel Guémar -
Jakub Jelinek -
Jeff Garzik -
John Reiser -
Josh Boyer -
Jud Craft -
Kevin Kofler -
Neal Gompa -
Peter Jones -
Rahul Sundaram -
Rik van Riel