Open GoogleCodeExporter opened 9 years ago
What makes you think the license of the build tool would affect the project?
Guichan
is not based on a build tool, it just ships with one. Neither the GPL nor the
LGPL
affect other software bundled in the same distribution.
That said, I'm all for going with one build tool instead of two. CMake is
probably
the one that works better overall. I'm currently still using autoconf though.
Original comment by b.lindeijer
on 9 Jun 2009 at 10:11
Björn, you once told me - when I wanted to switch build system - that it's a
good
idea to have autotools as most Linux distributions are familiar with autotools,
and I
think that's a good point.
Personally I don't like autotools at all, and I would much rather just use
CMake. I
once started to work on a switch to CMake, but at the moment non of the
examples are
built, which is a pity.
I think we should switch to CMake, but still keep the autotools stuff as it is,
perhaps update them when required or simply let users of autotools update it.
I don't know much about BSDBuild, but judging from their site I think CMake is
better.
Original comment by olof.nae...@gmail.com
on 10 Jun 2009 at 11:31
Ok, I mainly mentioned it because you can still run ./configure, make, and make
install through it just like you can with the GNOME tools, so to the user, it
would
remain invisible. The biggest difference is just the license for the build
tools.
Original comment by irar...@gmail.com
on 10 Jun 2009 at 4:09
Perhaps I phrased it poorly, Bjorn, but what I meant is that the default way of
compiling GUIChan right now (gnu build tools) makes it so that the code is
relicensed
as LGPL whether that was the intention of the person compiling it or not. The
issue
here isn't that the user shouldn't be able to do that if they don't want to,
just
that I don't think that any of the build solutions should impose a particular
license
on the user other than BSD, hence why I think that it should be dropped. And
like I
said in the previous post here, I was suggesting something like BSDBuild as a
replacement solely because it would remain invisible to the person compiling the
project on linux while keeping the standard make sequence that users on Linux
expect.
I'm sure there are other BSD solutions which might work as well, and CMake alone
might be alright, but it would be nice if a change to this was made as
invisible as
possible to any maintainers who are packaging this in a Linux distro, as well as
keeping everything BSD compatible unless a user overrides that themselves,
instead of
having the license addition imposed on them.
Personally, I'd like to continue to be able to run ./configure, make, and make
install as is, since I do use Linux and don't like to think a lot about special
compile instructions any time I need to rebuild a new package, and if that
means that
I'm submitting new build scripts in order to be able to have that convenience,
then I
suppose that's what I'll need to do. But I would like to be able to see the
GUIChan
library as a whole be usable as pure BSD through any of the build scripts,
since I
think that using gnu build tools breaks that.
Also, I don't know of any BSD project that uses the gnu build tools as well,
which is
what got me thinking about this in the first place.
Original comment by irar...@gmail.com
on 10 Jun 2009 at 6:00
I think I explained well enough that the license of the build tool does not
spread
out to Guichan, since they are two separate things that are not even based on
each
other. Building Guichan using GNU make does not cause the license of GNU make to
apply to Guichan. Just like you can edit images in GIMP without suddenly having
to
license them under the GPL.
Olof, maybe my opinion was stronger in the past, but if CMake can replace the
autotools completely then I think this isn't a bad idea. The one thing I am
missing
with CMake is the 'make dist' target, however I don't think you need this with
CMake
since you could probably just use 'git archive' to make the distribution too.
As for
easy to build, to a distribution this really shouldn't matter. All of KDE is
based on
CMake too, so they should already be familiar with it. And there is nothing more
complicated about running 'cmake .' instead of './configure'.
Original comment by b.lindeijer
on 10 Jun 2009 at 9:37
Then I guess we switch to CMake.
Original comment by olof.nae...@gmail.com
on 11 Jun 2009 at 6:27
Original issue reported on code.google.com by
irar...@gmail.com
on 8 Jun 2009 at 5:24