Re: autotools gives autopain
Davyd Madeley wrote: > Quoting James Henstridge <[EMAIL PROTECTED]>: > >> I get the feeling that scons plus something like bksys might be worth >> considering in the future, but it seems a bit immature right now. I'm >> sure it has benefits right now, such as removing libtool from the build >> process (which takes up a noticeable amount of time in builds), but it >> isn't clear that the benefits currently outweigh the switching costs. > > > What about platforms where libtool is required? Which platforms would they be? Don't all the platforms we support support shared libraries without libtool? My point above is that libtool-like functionality for abstracting the shared library build process should be possible from within an extensible build framework like scons. This eliminates the need to call a big-arse shell script that calls dozens of shell utilities (which is particularly slow on win32), so you just end up forking to call the compiler, linker, etc. James. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: autotools gives autopain
Quoting James Henstridge <[EMAIL PROTECTED]>: I get the feeling that scons plus something like bksys might be worth considering in the future, but it seems a bit immature right now. I'm sure it has benefits right now, such as removing libtool from the build process (which takes up a noticeable amount of time in builds), but it isn't clear that the benefits currently outweigh the switching costs. What about platforms where libtool is required? --d ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: autotools gives autopain
BJörn Lindqvist wrote:
>>>According to the devs, that is a feature of scons. This page has a
>>>workaround: http://www.scons.org/cgi-bin/wiki/ImportingEnvironmentSettings
>>>Although I think your real problem is badly written SConstruct-files.
>>>
>>>
>>>
>>It may be the fault of the person writing the SConstruct file, but it is
>>a problem that is not often encountered for autoconf/automake projects.
>>
>>
>
>Indeed. But considering that the workaround is less than 15 characters
>to type and that the scons developers probably have some good reasons
>for not inheriting the environment by default I don't think it's much
>to argue about.
>
>
>
>>>I think you are being unfair to scons. Ofcourse it is not right to
>>>hardwire architecture dependent paths in SConstruct-files, but that's
>>>not a problem with scons, it's a problem with bad SConstruct files.
>>>Likewise, someone could hardwire installation paths in Makefiles.
>>>
>>>
>>>
>>Again, this is not a problem often seen for programs using
>>autoconf/automake for the build system, so it really sounds like scons
>>just makes it easier for a developer to shoot themselves in the foot.
>>
>>(this is probably a slightly unfair comparison though: I am sure there
>>are areas where scons makes it easier for developers to do the right thing).
>>
>>
>
>Yes it is. You are comparing apples with oranges.
>
>make = scons
>autotools = bksys/project specific Python/???
>
>I think I may have misrepresented scons in this thread. I wrote
>"replace Autotools with scons." But that's not really true. What I
>really meant was "replace Autotools/make with scons and a
>configuration system written in Python around it." Apologises about
>that.
>
>
Okay, so I think we can pretty much ignore scons on its own as a build
solution, and instead should talk about frameworks built on top of it
(like bksys, which you mentioned).
>>Are there any particular medium complexity packages you could point out
>>using bksys? Have those modules been packaged by any Linux distros? If
>>so, did they need to resort to any ugly workarounds?
>>
>>
>
>rosegarden, kdissert and codeine. rosegarden and kdissert are packaged
>by Ubuntu. No clue about ugly workarounds.
>
>
Rosegarden in Ubuntu appears to be built with autoconf/make. The
"kdissert" package does appear to be using scons to build, the basic
steps being:
SCONS = scons --no-cache -Q
$(SCONS) configure prefix=/usr
$(SCONS)
DESTDIR=... $(SCONS) install
So it looks like scons+bksys handles a destdir build quite well. I
didn't check very closely to see if things like CFLAGS were getting
propagated correctly.
It seems that the kdissert tarball includes the bksys files. Is that
the intended way to handle things? This doesn't necessarily count
against it when comparing to autoconf though: autoconf based packages
end up carrying around a big generated configure script).
As far as replacing autoconf-style functionality though, it looks like
the bksys checks for each library are fairly long-winded compared to
what I'd write in an autoconf configure.in script:
http://websvn.kde.org/trunk/KDE/kdelibs/bksys/
Would developers be required to write scripts like these for every
library or header they want to check for?
Also, I haven't checked to see whether bksys provides something that is
equivalent to "make distcheck".
>>The command Stanislav gave approximates this if all files for the
>>program fall under /usr, but would not be enough if some files should go
>>under e.g. /etc. A DESTDIR install should rebase every installed file.
>>
>>
>
>In scons, the rough equivalent would be:
>
>opts = Options()
>opts.AddPathOption("destdir", "Base path for installed files", "/")
>opts.Update(env)
>
>And then prefix all installation paths with env["destdir"].
>
>
This is the sort of thing I'd hope that the build system does
automatically for me. It gets done automatically by automake.
I get the feeling that scons plus something like bksys might be worth
considering in the future, but it seems a bit immature right now. I'm
sure it has benefits right now, such as removing libtool from the build
process (which takes up a noticeable amount of time in builds), but it
isn't clear that the benefits currently outweigh the switching costs.
James.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: autotools gives autopain
BJörn Lindqvist wrote: > > 1) SCons intentionally ignores most standard *FLAGS (documentation says > > so). > According to the devs, that is a feature of scons. This page has a > workaround: http://www.scons.org/cgi-bin/wiki/ImportingEnvironmentSettings > Although I think your real problem is badly written SConstruct-files. Thanks for the link. It is a feature for reproducible building of a binary. For distribution-release packaging it is a problem - distribution maintainer needs to change the whole distribution by changing of a few variables (e. g. RPM_OPT_FLAGS -> CFLAGS). > > 2) It is hard to change hardwired default paths and change, say /usr/lib > > to /usr/lib64 for all packages. > I think you are being unfair to scons. Ofcourse it is not right to > hardwire architecture dependent paths in SConstruct-files, but that's > not a problem with scons, it's a problem with bad SConstruct files. It is a problem of both, most paths are hardwired in SConstruct files, the rest in SCons. My problem was http://sourceforge.net/tracker/index.php?func=detail&aid=1368255&group_id=30337&atid=398971 > Likewise, someone could hardwire installation paths in Makefiles. > Scons really is nothing more than a very nice make-replacement inside > a very nice programming language. A fairer comparision would be > bksys/scons (which kde is built with) against autotools/make. It means, that projects using scons without bksys are in the same situation as projects using make without autotools 10 years ago. Autotools were written just to prevent hardwired paths and features in makefiles. And bksys could change the quality of SConstruct files. >From the view of the package maintainer, I would prefer move from make+autotools to bksys+scons and discourage move from autools+make to plain scons. -- Best Regards / S pozdravem, Stanislav Brabec software developer - SuSE CR, s. r. o. e-mail: [EMAIL PROTECTED] Drahobejlova 27 tel: +420 296 542 382 190 00 Praha 9fax: +420 296 542 374 Czech Republichttp://www.suse.cz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: autotools gives autopain
> >According to the devs, that is a feature of scons. This page has a
> >workaround: http://www.scons.org/cgi-bin/wiki/ImportingEnvironmentSettings
> >Although I think your real problem is badly written SConstruct-files.
> >
> It may be the fault of the person writing the SConstruct file, but it is
> a problem that is not often encountered for autoconf/automake projects.
Indeed. But considering that the workaround is less than 15 characters
to type and that the scons developers probably have some good reasons
for not inheriting the environment by default I don't think it's much
to argue about.
> >I think you are being unfair to scons. Ofcourse it is not right to
> >hardwire architecture dependent paths in SConstruct-files, but that's
> >not a problem with scons, it's a problem with bad SConstruct files.
> >Likewise, someone could hardwire installation paths in Makefiles.
> >
> Again, this is not a problem often seen for programs using
> autoconf/automake for the build system, so it really sounds like scons
> just makes it easier for a developer to shoot themselves in the foot.
>
> (this is probably a slightly unfair comparison though: I am sure there
> are areas where scons makes it easier for developers to do the right thing).
Yes it is. You are comparing apples with oranges.
make = scons
autotools = bksys/project specific Python/???
I think I may have misrepresented scons in this thread. I wrote
"replace Autotools with scons." But that's not really true. What I
really meant was "replace Autotools/make with scons and a
configuration system written in Python around it." Apologises about
that.
> Are there any particular medium complexity packages you could point out
> using bksys? Have those modules been packaged by any Linux distros? If
> so, did they need to resort to any ugly workarounds?
rosegarden, kdissert and codeine. rosegarden and kdissert are packaged
by Ubuntu. No clue about ugly workarounds.
> The command Stanislav gave approximates this if all files for the
> program fall under /usr, but would not be enough if some files should go
> under e.g. /etc. A DESTDIR install should rebase every installed file.
In scons, the rough equivalent would be:
opts = Options()
opts.AddPathOption("destdir", "Base path for installed files", "/")
opts.Update(env)
And then prefix all installation paths with env["destdir"].
--
mvh Björn
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: autotools gives autopain
BJörn Lindqvist wrote: >>1) SCons intentionally ignores most standard *FLAGS (documentation says >>so). You have to edit one or more SConstruct files to force flags you >>want for your platform (it's a SuSE packaging convention), not flags >>decided by somebody for it. This is the simplest solution, working only >>in some projects: >> >> > >According to the devs, that is a feature of scons. This page has a >workaround: http://www.scons.org/cgi-bin/wiki/ImportingEnvironmentSettings >Although I think your real problem is badly written SConstruct-files. > > It may be the fault of the person writing the SConstruct file, but it is a problem that is not often encountered for autoconf/automake projects. >>2) It is hard to change hardwired default paths and change, say /usr/lib >>to /usr/lib64 for all packages. It took me about 4 hours of debugging to >>get rid all of -L/usr/lib causing build failures. This covers only most >>common problems: >> >> > >I think you are being unfair to scons. Ofcourse it is not right to >hardwire architecture dependent paths in SConstruct-files, but that's >not a problem with scons, it's a problem with bad SConstruct files. >Likewise, someone could hardwire installation paths in Makefiles. > > Again, this is not a problem often seen for programs using autoconf/automake for the build system, so it really sounds like scons just makes it easier for a developer to shoot themselves in the foot. (this is probably a slightly unfair comparison though: I am sure there are areas where scons makes it easier for developers to do the right thing). >Scons really is nothing more than a very nice make-replacement inside >a very nice programming language. A fairer comparision would be >bksys/scons (which kde is built with) against autotools/make. > > Are there any particular medium complexity packages you could point out using bksys? Have those modules been packaged by any Linux distros? If so, did they need to resort to any ugly workarounds? >>4) I did not find any DESTDIR support, needed for comfortable packaging >>without root privileges. One has to go back 10 years and use: >> >>scons PREFIX=$RPM_BUILD_ROOT/usr install >> >> > >What is destdir? Can you explain what the equivalent autotools/make >thing is and what it does? > > The ability to build a program with a certain set of paths, and then add a prefix to all those paths when installing the files, so that the contents of that directory can be packaged. The command Stanislav gave approximates this if all files for the program fall under /usr, but would not be enough if some files should go under e.g. /etc. A DESTDIR install should rebase every installed file. James. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: autotools gives autopain
On 1/3/06, BJörn Lindqvist <[EMAIL PROTECTED]> wrote: > > 4) I did not find any DESTDIR support, needed for comfortable packaging > > without root privileges. One has to go back 10 years and use: > > > > scons PREFIX=$RPM_BUILD_ROOT/usr install > > What is destdir? Can you explain what the equivalent autotools/make > thing is and what it does? After software is compiled, it needs to be installed in some certain path before packaging, say /home/abc/tmp. Using root privilege for packaging is dangerous and discouraged. In above example, this is achieved by: (assuming packager logged in as user 'abc' with normal user privilege) make install DESTDIR=/home/abc/tmp Then binaries to be placed in /usr/bin are installed into /home/abc/tmp/usr/bin instead, and so on. Autotools generates makefiles that contain DESTDIR support by default, like (of course this is just an example): DESTDIR= install-bin: -mkdir -p $(DESTDIR)$(bindir) install -m 755 -c foobar $(DESTDIR)$(bindir)/foobar So packager can redefine DESTDIR freely during 'make install'. Abel > > -- > mvh Björn > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list > -- Abel Cheung (GPG Key: 0xC67186FF) Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF * GNOME Hong Kong - http://www.gnome.hk/ * Opensource Application Knowledge Assoc. - http://oaka.org/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: autotools gives autopain
On 1/3/06, Stanislav Brabec <[EMAIL PROTECTED]> wrote:
>
> I have to package a few packages using scons. Creating an RPM package
> from scons based project became my nightmare. Prepare a working lprof
> package for SuSE AMD64 took me about 6 hours of editing and debugging of
> scons files and finally it was impossible without patching many files
> and scons itself.
Stanislav, I have to agree 101% with this. A few months ago I attempted
to package gscore as RPM, and it took me several hours as well in order
to trace 64-bit arch problem and fix DESTDIR as well, though not as serious
as modifying scons itself.
If it is as BJörn said, that all these problems are caused by bad SConstruct
file, then probably most (if not all) software contains badly written
SConstruct files. Indeed from my limited experience with scons enabled
packages, quite a lot of SConstruct files contain many hardwired paths.
Abel
>
> Maybe I am doing something incorrectly. If you can advice on creating a
> distribution packages from scons based projects, I will be glad.
>
>
> 1) SCons intentionally ignores most standard *FLAGS (documentation says
> so). You have to edit one or more SConstruct files to force flags you
> want for your platform (it's a SuSE packaging convention), not flags
> decided by somebody for it. This is the simplest solution, working only
> in some projects:
>
> export CFLAGS="$RPM_OPT_FLAGS"
> if test -z "$CFLAGS" ; then
> export CSCFLAGS=
> else
> CSCFLAGS="${CFLAGS// /', '}"
> export CSCFLAGS="'$CSCFLAGS'"
> fi
> echo "env.Append(CCFLAGS = [$CSCFLAGS])" >>SConstruct
>
>
> > 2. Scons is simple to learn, Autotools is not.
>
> 2) It is hard to change hardwired default paths and change, say /usr/lib
> to /usr/lib64 for all packages. It took me about 4 hours of debugging to
> get rid all of -L/usr/lib causing build failures. This covers only most
> common problems:
>
> (
> find -name SConstruct
> find -name SConscript
> echo package.pro build_config.py
> find -name Makefile
> ) | while read ; do
> sed -i "
> s:/lib:/%_lib:g
> s:src/%_lib:src/lib:g
> " $REPLY
> done
>
> > 1. Scons is simply technically superior to GNU Autotools - with a big
> >margin.
>
> 3) It is hard to provide custom path for libraries. One again one needs
> to to platform dependent editing of SConstruct file to do it.
>
> patch < --- SConstruct
> +++ SConstruct
> @@ -79,20 +79,20 @@
> extra_includes = []
> # z library information
> z_lib = ['z']
> - z_libpath = ['/usr/lib']
> + z_libpath = ['/usr/%_lib']
> z_include = ['/usr/include']
> # png library information
> png_lib = ['png']
> - png_libpath = ['/usr/lib']
> + png_libpath = ['/usr/%_lib']
> png_include = ['/usr/include']
> # jpeg library information
> jpeg_lib = ['jpeg']
> - jpeg_libpath = ['/usr/lib']
> + jpeg_libpath = ['/usr/%_lib']
> jpeg_include = ['/usr/include']
> # OpenGL library information
> opengl_lib = ['GL', 'GLU']
> - opengl_static = ['/usr/lib/libGL.a', '/usr/lib/libGLU.a']
> - opengl_libpath = ['/usr/lib', '/usr/X11R6/lib']
> + opengl_static = ['/usr/%_lib/libGL.a', '/usr/%_lib/libGLU.a']
> + opengl_libpath = ['/usr/%_lib', '/usr/X11R6/%_lib']
> opengl_include = ['/usr/include', '/usr/X11R6/include']
> # SDL library information
> sdl_env.ParseConfig ('sdl-config --cflags --libs')
> EOF
>
>
> 4) I did not find any DESTDIR support, needed for comfortable packaging
> without root privileges. One has to go back 10 years and use:
>
> scons PREFIX=$RPM_BUILD_ROOT/usr install
>
> Sometimes you have to explicitly add more variables or even edit
> SConstruct before calling "scons install".
>
> --
> Best Regards / S pozdravem,
>
> Stanislav Brabec
> software developer
> -
> SuSE CR, s. r. o. e-mail: [EMAIL PROTECTED]
> Drahobejlova 27 tel: +420 296 542 382
> 190 00 Praha 9fax: +420 296 542 374
> Czech Republichttp://www.suse.cz/
>
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
--
Abel Cheung (GPG Key: 0xC67186FF)
Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF
* GNOME Hong Kong - http://www.gnome.hk/
* Opensource Application Knowledge Assoc. - http://oaka.org/
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: autotools gives autopain
> 1) SCons intentionally ignores most standard *FLAGS (documentation says > so). You have to edit one or more SConstruct files to force flags you > want for your platform (it's a SuSE packaging convention), not flags > decided by somebody for it. This is the simplest solution, working only > in some projects: According to the devs, that is a feature of scons. This page has a workaround: http://www.scons.org/cgi-bin/wiki/ImportingEnvironmentSettings Although I think your real problem is badly written SConstruct-files. > 2) It is hard to change hardwired default paths and change, say /usr/lib > to /usr/lib64 for all packages. It took me about 4 hours of debugging to > get rid all of -L/usr/lib causing build failures. This covers only most > common problems: I think you are being unfair to scons. Ofcourse it is not right to hardwire architecture dependent paths in SConstruct-files, but that's not a problem with scons, it's a problem with bad SConstruct files. Likewise, someone could hardwire installation paths in Makefiles. Scons really is nothing more than a very nice make-replacement inside a very nice programming language. A fairer comparision would be bksys/scons (which kde is built with) against autotools/make. > 4) I did not find any DESTDIR support, needed for comfortable packaging > without root privileges. One has to go back 10 years and use: > > scons PREFIX=$RPM_BUILD_ROOT/usr install What is destdir? Can you explain what the equivalent autotools/make thing is and what it does? -- mvh Björn ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: autotools gives autopain
BJörn Lindqvist wrote:
> Gnome currently uses the GNU Autotools for building all
> projects. Autotools is hard to work with and complicated and there are
> lots of techically superior build systems out there. Therefore, I
> suggest that GNOME should gradually replace Autotools with scons
> (www.scons.org). My arguments are:
I have to package a few packages using scons. Creating an RPM package
from scons based project became my nightmare. Prepare a working lprof
package for SuSE AMD64 took me about 6 hours of editing and debugging of
scons files and finally it was impossible without patching many files
and scons itself.
Maybe I am doing something incorrectly. If you can advice on creating a
distribution packages from scons based projects, I will be glad.
1) SCons intentionally ignores most standard *FLAGS (documentation says
so). You have to edit one or more SConstruct files to force flags you
want for your platform (it's a SuSE packaging convention), not flags
decided by somebody for it. This is the simplest solution, working only
in some projects:
export CFLAGS="$RPM_OPT_FLAGS"
if test -z "$CFLAGS" ; then
export CSCFLAGS=
else
CSCFLAGS="${CFLAGS// /', '}"
export CSCFLAGS="'$CSCFLAGS'"
fi
echo "env.Append(CCFLAGS = [$CSCFLAGS])" >>SConstruct
> 2. Scons is simple to learn, Autotools is not.
2) It is hard to change hardwired default paths and change, say /usr/lib
to /usr/lib64 for all packages. It took me about 4 hours of debugging to
get rid all of -L/usr/lib causing build failures. This covers only most
common problems:
(
find -name SConstruct
find -name SConscript
echo package.pro build_config.py
find -name Makefile
) | while read ; do
sed -i "
s:/lib:/%_lib:g
s:src/%_lib:src/lib:g
" $REPLY
done
> 1. Scons is simply technically superior to GNU Autotools - with a big
>margin.
3) It is hard to provide custom path for libraries. One again one needs
to to platform dependent editing of SConstruct file to do it.
patch
Re: autotools gives autopain
Hi, Op Sat, 17 Dec 2005 13:37:00 -0500, schreef Tom von Schwerdtner: > Another side of the same coin, how much further along would GNOME be if we > weren't chained to autotools? That's an interesting question :-) Anyhow, I'm not pretending to know enough about this subject matter to make authorative statements about it, but I came across the A-A-P project today that I think is relevant: http://www.a-a-p.org/ "A-A-P makes it easy to locate, download, build and install software. It also supports browsing source code, developing programs, managing different versions and distribution of software and documentation. This means that A-A-P is useful both for users and for developers." (interestingly, the site is maintained by Bram Moolenaar) Furthermore, a Freshmeat article on alternatives for make: http://freshmeat.net/articles/view/1715/ and http://freshmeat.net/articles/view/1702/ I hope this is helpful to the discussion. :) regards, -- Reinout van Schouwen ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: autotools gives autopain
For the sake of this discussion, I've been trying to get pygtk to build with scons during this weekend. Yes, it took me many hours of fun work to get pygtk minimally converted. And it's not finished. Equivalents to 'make dist' and 'make distcheck' are not implemented, and I suspect they will take some effort. So, definitely scons is not ready for GNOME yet; it provides basic infrastructure, but lacks some high-level features (eg. I had to reimplement PKG_CHECK_MODULES, AM_PATH_PYTHON, and AM_CHECK_PYTHON_HEADERS) and policy (eg. no concept of prefix, bindir, datadir, etc.). Nonetheless, it is clear to me now that scons is an order of magnitude more clean (detection+build logic are placed together, one language instead of m4/make/sh mix) and maintainable than autotools, and if we strive to build a more constrained build system on top of it like the KDE guys did, it will serve GNOME much better in the long term, IMHO. Just though I'd let you know of my weekend research... :) Patch: http://www.gnome.org/~gjc/pygtk-scons.diff -- Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> The universe is always one step beyond logic signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: autotools gives autopain
Hi, Le dimanche 18 décembre 2005 à 03:58 +0100, Samuel Abels a écrit : > On So, 2005-12-18 at 01:37 +0100, Thomas Vander Stichele wrote: > > Hi, > > > > first of all, I love python. > > > > > 1. Scons is simply technically superior to GNU Autotools - with a big > > >margin. > > > > Saying this does not make it automatically true. Some further > > explanation required. > > I'll give it a try: > > - The separation of Autoconf and Automake into two layers makes it > difficult to debug, because you can not easily tell which of the macros > generated a particular line in the Makefile. I don't remember having to debug anything for this, but it might have happened. Maybe it wasn't so difficult :-) I agree that if people need to debug often those things, then it might be painful. But I'm not sure it's the case. > - Makefiles are very large and thus difficult to understand. I don't read Makefile. I read Makefile.am. > - New users need to learn to write in multiple different languages (M4, > shell, and make's syntax) Those languages are not that hard, and people can help if necessary (or docs, as Davyd pointed out). > - It ships a lot of overhead in every single package. Lot of overhead = lot of files or lot of space? If it's files, well... is it that important? > - Auto-generating stuff and integration with code generators is often > less than intuitive. (Thinking of Makefile.in.in.in and the likes.) True :-) > - The syntax of any of the languages does probably not meet modern > standards of readability. (I might add an IMO here, but may I doubt > whether many are going to disagree?) This is more or less the same point than "new users need to learn to write in multiple different languages": once you know these languages, you can read them. But they're not the most pretty languages out there. > Now I do not claim that Scons fixes all of Automake's issues. Scons has > a lot of problems of it's own. But, some of the most glaring advantages > of Scons are IMO: > > - Most importantly, it can be fixed. Yes, it has a lot of problems that > need to be looked into. Many of them relate to the fact that not a lot > of functions are implemented yet. But there are no design decisions in > the way to make it work better. New releases come with new features and > it is constantly being improved. Autotools' problems, on the other hand, > are mostly design related and thus, haven't improved significantly in > the last decade. Yes, Autotools do work, but so does Scons. Stop. I don't want to update the build system every time there's a new release of Scons. When Scons is ready, why not. But if it's not ready, I won't switch before all the required features are in. [...] > All that said, I see no reason NOT to implement Scons in a project if > somebody is willing to do it. It can be done in parallel with Automake, > so you could still choose. Even if Scons is used as a replacement, > wrapping a Makefile around the Scons installer is trivial, so "make" is > still going to work. I do not want to update two build systems either :-) To sum up my opinion: if people can show us it's ready and we don't have to wait for features, then I won't see a problem with a migration. If it's not ready, implement all the missing features and propose it again :-) We have autotools now, they're working, so we can wait a bit so that another system is ready to replace it. Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: autotools gives autopain
On So, 2005-12-18 at 01:37 +0100, Thomas Vander Stichele wrote: > Hi, > > first of all, I love python. > > > 1. Scons is simply technically superior to GNU Autotools - with a big > >margin. > > Saying this does not make it automatically true. Some further > explanation required. I'll give it a try: - The separation of Autoconf and Automake into two layers makes it difficult to debug, because you can not easily tell which of the macros generated a particular line in the Makefile. - Makefiles are very large and thus difficult to understand. - New users need to learn to write in multiple different languages (M4, shell, and make's syntax) - It ships a lot of overhead in every single package. - Auto-generating stuff and integration with code generators is often less than intuitive. (Thinking of Makefile.in.in.in and the likes.) - The syntax of any of the languages does probably not meet modern standards of readability. (I might add an IMO here, but may I doubt whether many are going to disagree?) Now I do not claim that Scons fixes all of Automake's issues. Scons has a lot of problems of it's own. But, some of the most glaring advantages of Scons are IMO: - Most importantly, it can be fixed. Yes, it has a lot of problems that need to be looked into. Many of them relate to the fact that not a lot of functions are implemented yet. But there are no design decisions in the way to make it work better. New releases come with new features and it is constantly being improved. Autotools' problems, on the other hand, are mostly design related and thus, haven't improved significantly in the last decade. Yes, Autotools do work, but so does Scons. - Through it's use of object orientation it is easier to create and combine modules, and to share code. - Choose to include functions from a large number of Python libraries. - By using md5 hashes it determines more accurately/quickly when or when not to rebuild a file/project. (make uses the mtime) - Scons is very lightweight because it places only one single file in each directory. That also makes it much easier to get into. - I am not the biggest fan of Python, but I have to give them this: In comparison with shell, or M4, the syntax is more readable. - Drifting slightly off topic: The fact that a Scons installation is required on the user's system can also be an advantage. For example, it makes it possible (in theory) for users to run different frontends on top of the Scons build system. For example, on one user's desktop calling "scons install" (or clicking the SConstruct file) is going to pop up a GTK UI, on another user's system the CLI is used. All that said, I see no reason NOT to implement Scons in a project if somebody is willing to do it. It can be done in parallel with Automake, so you could still choose. Even if Scons is used as a replacement, wrapping a Makefile around the Scons installer is trivial, so "make" is still going to work. -Samuel -- -- | Samuel Abels | http://www.debain.org| | spam2 ad debain dod org | knipknap ad jabber dod org | -- ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: autotools gives autopain
On Sat, 2005-12-17 at 18:41 +0100, Fernando Herrera wrote: >2) It's very slow. Automake regeneration is slow and configure scripts are. I don't see how we can get around any speed issues here. The problem is having to compile and run all of those little tests on the platform. Any serious build system would want to compile and run the same sets of tests to work out what manner of libc and such we have available. >3) It's difficult to maintain I think simple documentation with clear examples would oft aid in understanding. > a) They work on all the GNOME platform and OS combinations (Linux, > FreeBSD, Hurd, OpenBSD, NetBSD, Solaris, AIX x i386, powepc, > x64) Let us not forget Tru64 and IRIX on Alpha and MIPS (both of these have some manner of support, in addition to being hell-on-earth platforms to deal with for compatibility). --d -- Davyd Madeley http://www.davyd.id.au/ 08B0 341A 0B9B 08BB 2118 C060 2EDD BB4F 5191 6CDA ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: autotools gives autopain
Hi, first of all, I love python. > 1. Scons is simply technically superior to GNU Autotools - with a big >margin. Saying this does not make it automatically true. Some further explanation required. > 2. Scons is simple to learn, Autotools is not. True. However, autotools is already learned by enough people, scons is not. > 3. KDE has already migrated to scons. Not a useful argument. > 1. Autotools have worked so far, why switch? > >- Because scons is easier and better. It is easier, but not better. > In the long run the benefits > of a good build system outweighs the disadvantages of switching > to it. There are not much benefits to be had from switching - autotools is not a bad build system. > 5. The migration to SCons will be really painful. > >- Let's look at how KDE managed and learn from them. No change is > without a price, but going from autotools to scons is worth it. Saying it doesn't make it true. FWIW - last time I checked, scons *still* did not support a basic operation any maintainer needs called "make distcheck". This is a minimum IMO - without it we shouldn't even discuss switching. Thomas Dave/Dina : future TV today ! - http://www.davedina.org/ <-*- thomas (dot) apestaart (dot) org -*-> "That's funny ..." "But it's not real !" "I hope not, it's funnier when it is real" <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.fm/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: autotools gives autopain
On Fr, 2005-12-16 at 17:23 +0100, BJörn Lindqvist wrote: > 3. KDE has already migrated to scons. Note that KDE uses bksys, which is a framework that is based on Scons. "bksys aims at replacing completely autotools for common projects, so this goes way beyond SCons' main goals." http://dot.kde.org/1126452494/ I have also used Scons in some smaller projects, and while I believe that it has potential, using Scons alone without additional libraries can currently also give you headaches. For example, two difficulties that I encountered: - There is a lack of good default functions, even for basic functionality. For example, there is no integrated way to generate C header files (like config.h). (At least there wasn't when I last tried it a couple of months ago.) - Due to the lack of convenience libraries and the fact that one file can not be contained in multiple targets at once, it is hard to integrate unit tests into the build process. However, Scons is flexible enough so that you can work around those issues by creating you own functions, and in many cases the resulting SConstruct file will probably still be simpler than an equivalent configure.am + Makefile. Nonetheless, without a powerful framework around it there will IMO be little immediate gain in the switch. It does put GNOME in a position from which it can improve the build system more easily though. This is probably also the reason why KDE created bksys (but I have not looked into it and have not spoken to the developer to back this up). My personal opinion is that the switch will help in the long run despite the weaknesses of Scons, as it opens the door to move forward. -Samuel -- -- | Samuel Abels | http://www.debain.org| | spam2 ad debain dod org | knipknap ad jabber dod org | -- ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: autotools gives autopain
BJörn Lindqvist wrote: I hope my arguments are very convincing and not inflammatory. Let's get some good discussion going. -- mvh Björn Do you happen to know how easy cross compiling is with SCons? What is the SCons equivalent of: ./configure --host=i586-mingw32msvc \ PKG_CONFIG_PATH=/home/sam/src/solar/win32/lib/pkgconfig/ LDFLAGS=-Wl,--enable-runtime-pseudo-reloc which is what I use to build a project of mine for Windows, on my Debian machine. It took me long enough to work out how to do this with the Autotools. :) -- Sam Morris http://robots.org.uk/ PGP key id 5EA01078 3412 EA18 1277 354B 991B C869 B219 7FDB 5EA0 1078 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: autotools gives autopain
On 12/17/05, Fernando Herrera <[EMAIL PROTECTED]> wrote:
>1) We need to install 5 or 6 different versions of the autotools in
> order to bootstrap GNOME from CVS
>2) It's very slow. Automake regeneration is slow and configure scripts are.
>3) It's difficult to maintain
4) Most people don't actually understand what they're doing, they just
copy and paste from another configure.{in|ac} (make your mind up
autoconf) written by someone else who doesn't understand whats going
on.
iain
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: autotools gives autopain
On 12/16/05, Andy Tai <[EMAIL PROTECTED]> wrote: > Interesting... this looks like a solution looking for a problem. There is > no problem the autotools present to GNOME that could not be solved. All the > weaknesses you listed about autotools clearly are not issues for GNOME > developers, or else GNOME won't be where it is today. Another side of the same coin, how much further along would GNOME be if we weren't chained to autotools? Autotooling a new project or adjusting autofoo in an existing project is a serious pain and requires a fair amount of research and head banging if you can't enlist the help of "someone who knows". If we want to encourage people to contribute to gnome and to write new software for gnome we should put some attention into lowering the barriers of entry and simplifying the development process. Scons may not be the answer, but it's a topic that needs discussion. Another point that I think is important but I haven't seen mentioned is how easy (or difficult) it might be to integrate whatever tools we use into an IDE (be it anjuta, monodevelop or whatever else). Regards, Tom ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: autotools gives autopain
On 12/17/05, Andy Tai <[EMAIL PROTECTED]> wrote: > Interesting... this looks like a solution looking for a problem. There is > no problem the autotools present to GNOME that could not be solved. All the > weaknesses you listed about autotools clearly are not issues for GNOME > developers, or else GNOME won't be where it is today. Hi, I think we should be pragmatic in this discussion. What issues with autotools make us cry? (and "us" are maintainers, developers and packagers): 1) We need to install 5 or 6 different versions of the autotools in order to bootstrap GNOME from CVS 2) It's very slow. Automake regeneration is slow and configure scripts are. 3) It's difficult to maintain But before considering a new solution we need to be sure that this new solution gives us all the good things autotools gave us in the past: a) They work on all the GNOME platform and OS combinations (Linux, FreeBSD, Hurd, OpenBSD, NetBSD, Solaris, AIX x i386, powepc, x64) b) They are correctly documented c) They allow us to compile CVS versions and make tarballs with just 1 line. So if scons can guarantee us a, b and c, and it fixes 1,2 and 3 I think we should consider them. Salu2 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: autotools gives autopain
Interesting... this looks like a solution looking for a problem. There is no problem the autotools present to GNOME that could not be solved. All the weaknesses you listed about autotools clearly are not issues for GNOME developers, or else GNOME won't be where it is today.On 12/16/05, BJörn Lindqvist <[EMAIL PROTECTED]> wrote: Gnome currently uses the GNU Autotools for building allprojects. Autotools is hard to work with and complicated and there arelots of techically superior build systems out there. Therefore, Isuggest that GNOME should gradually replace Autotools with scons (www.scons.org). ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: autotools gives autopain
On Sat, 2005-12-17 at 13:47 +0300, Nickolay V. Shmyrev wrote: > You are probably not correct here Davyd, current gnome builds do require > pkg-config to be installed. I was specifically referring to autoconf and automake-*, however it also applies to intltool, libtool and a bunch of other things (I think). It is my opinion that while a build time dependence on pkg-config is not desirable, sometimes it is unavoidable or even darned handy. In these cases no build system on the planet is going to get us away from pkg-config (I would also like to point out that pkg-config is 100x better than anything else similar, and its use takes an awful lot of the pain out of the usage of autoconf. --d -- Davyd Madeley http://www.davyd.id.au/ 08B0 341A 0B9B 08BB 2118 C060 2EDD BB4F 5191 6CDA ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: autotools gives autopain
On 12/17/05, Davyd Madeley <[EMAIL PROTECTED]> wrote: > I do not think we should switch. Ditto. >From my understanding there is no easy way to do make dist and make distcheck targets with scons. (Not that I've used it personally, except for building a few things...) iain ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: autotools gives autopain
Nickolay V. Shmyrev wrote: В Сбт, 17/12/2005 в 15:03 +0800, Davyd Madeley пишет: On Fri, 2005-12-16 at 22:26 +, Andrew Sobala wrote: Sean D'Epagnier wrote: Isn't it true that scons requires you download and install it as an extra program to use it? Many users may not have scons and may not want to install it, but do want to install gnome (by compiling from source code). This is identical to the situation for autotools. Only to run autogen, not configure. --d You are probably not correct here Davyd, current gnome builds do require pkg-config to be installed. pkg-config is not tied to any specific build systems. If we were to switch to SCons it'll still be required. However, pkg-config provides a few macros to integrate nicely with autotools, these and quite a few other scripts needs to be rewritten for SCons. Johan Dahlin ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: autotools gives autopain
В Сбт, 17/12/2005 в 15:03 +0800, Davyd Madeley пишет: > On Fri, 2005-12-16 at 22:26 +, Andrew Sobala wrote: > > Sean D'Epagnier wrote: > > > > > Isn't it true that scons requires you download and install it as an > > > extra program to use it? Many users may not have scons and may not > > > want to install it, but do want to install gnome (by compiling from > > > source code). > > > > This is identical to the situation for autotools. > > Only to run autogen, not configure. > > --d > You are probably not correct here Davyd, current gnome builds do require pkg-config to be installed. Btw, does anybody know if it possible to do things like make distcheck with scons? It seems to be very important feature of autotools. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: autotools gives autopain
On Fri, 2005-12-16 at 22:26 +, Andrew Sobala wrote: > Sean D'Epagnier wrote: > > > Isn't it true that scons requires you download and install it as an > > extra program to use it? Many users may not have scons and may not > > want to install it, but do want to install gnome (by compiling from > > source code). > > This is identical to the situation for autotools. Only to run autogen, not configure. --d -- Davyd Madeley http://www.davyd.id.au/ 08B0 341A 0B9B 08BB 2118 C060 2EDD BB4F 5191 6CDA ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: autotools gives autopain
On Fri, 2005-12-16 at 17:23 +0100, BJörn Lindqvist wrote: > Gnome currently uses the GNU Autotools for building all > projects. Autotools is hard to work with and complicated and there are > lots of techically superior build systems out there. Therefore, I > suggest that GNOME should gradually replace Autotools with scons > (www.scons.org). My arguments are: > 1. Scons is simply technically superior to GNU Autotools - with a big >margin. > 2. Scons is simple to learn, Autotools is not. Having look at and evaluated Scons for use in migrating from other projects and building new projects... Scons does not really solve the problem of building software better than autotools does. While the base syntax is more forgiving and flexible than autotools, writing your own macros or doing advanced/complicated things with your build process is just as much as a nightmare. In addition to this, there exists today a wide range of precooked autotools macros for implementing many tasks. Additionally, the GNOME macros make implementing builds in autotools almost dreamy and as James pointed out, an autotools generated tarball requires nothing more than a vaguely compliant shell and a vaguely compliant Make to build. One of the problems with autotools is there is a large learning curve towards writing clean autoconf and automake files. Perhaps this can be mitigated through some simpler documentation. I will see about contributing my work's autotools notes back to the community. I do not think we should switch. --d -- Davyd Madeley http://www.davyd.id.au/ 08B0 341A 0B9B 08BB 2118 C060 2EDD BB4F 5191 6CDA ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: autotools gives autopain
Andrew Sobala wrote: > Sean D'Epagnier wrote: > >> Isn't it true that scons requires you download and install it as an >> extra program to use it? Many users may not have scons and may not >> want to install it, but do want to install gnome (by compiling from >> source code). > > > This is identical to the situation for autotools. The only component you really need to build an autotooled package from a tarball is make and the various standard shell utilities, which are generally installed already. To do the same with a package using scons to build, you'd need to install scons. So it is true that you need to install some tool to build the package in both cases, but people are more likely to notice in the scons case. James. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: autotools gives autopain
On Sat, Dec 17, 2005 at 12:34:20AM +0100, Rodrigo Moya wrote: > On Fri, 2005-12-16 at 18:13 +0100, BJörn Lindqvist wrote: > > > > Gnome currently uses the GNU Autotools for building all projects. > > > > Autotools is hard to work with and complicated and there are lots of > > > > techically superior build systems out there. Therefore, I suggest that > > > > GNOME should gradually replace Autotools with scons (www.scons.org). > > > > > > I'd suggest that this would not be a very interesting topic of discussion > > > on > > > this list *unless* you converted one of the existing GNOME modules to > > > scons > > > > Right. That's the easy part. Any GNOME modules wanna sign up for a > > FREE conversion to scons? Limited supply, order now! > > > starting with simplest stuff, like small applications or libraries, like > libgnome, libgnomeui, might be a good start If you use the baz mirrors you can follow cvs while making the conversion and collaborate with whoever else wants to help you. sri ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: autotools gives autopain
Sean D'Epagnier wrote: Isn't it true that scons requires you download and install it as an extra program to use it? Many users may not have scons and may not want to install it, but do want to install gnome (by compiling from source code). This is identical to the situation for autotools. -- Andrew ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: autotools gives autopain
On Fri, 2005-12-16 at 18:13 +0100, BJörn Lindqvist wrote: > > > Gnome currently uses the GNU Autotools for building all projects. > > > Autotools is hard to work with and complicated and there are lots of > > > techically superior build systems out there. Therefore, I suggest that > > > GNOME should gradually replace Autotools with scons (www.scons.org). > > > > I'd suggest that this would not be a very interesting topic of discussion on > > this list *unless* you converted one of the existing GNOME modules to scons > > Right. That's the easy part. Any GNOME modules wanna sign up for a > FREE conversion to scons? Limited supply, order now! > starting with simplest stuff, like small applications or libraries, like libgnome, libgnomeui, might be a good start -- Rodrigo Moya <[EMAIL PROTECTED]> ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: autotools gives autopain
Isn't it true that scons requires you download and install it as an extra program to use it? Many users may not have scons and may not want to install it, but do want to install gnome (by compiling from source code). BJörn Lindqvist: In the mean time.. why don't you write up some Sconstructs for certain gnome packages and see if you can get them to build. Maybe there is a migration script you can use to generate them from the existing automake headers.. If you can get a complete gnome system to build with scons, this migration might happen (I know I will certainly test it out for you)On 12/16/05, Shaun McCance <[EMAIL PROTECTED]> wrote: On Fri, 2005-12-16 at 17:23 +0100, BJörn Lindqvist wrote:> (Sorry for the inflammatory subject, it is meant to be> humoristic. Although it's true :))>> Gnome currently uses the GNU Autotools for building all > projects. Autotools is hard to work with and complicated and there are> lots of techically superior build systems out there. Therefore, I> suggest that GNOME should gradually replace Autotools with scons > (www.scons.org). My arguments are:>> 1. Scons is simply technically superior to GNU Autotools - with a big>margin.>> 2. Scons is simple to learn, Autotools is not. >> 3. KDE has already migrated to scons.>> I suggest people give scons a try and it will become apparent how good> scons is (and how bad autotools is). Now my counter-arguments to the > counter-arguments I'm sure people will come up with:[snip some good counter-arguments]One thing we have to consider is that a few modules providebuild utilities for other modules to use: intltool, gtk-doc, and gnome-doc-utils are a few. Pretty much anything thatprovides a library probably uses gtk-doc. Anything providinguser help should use gnome-doc-utils. And almost every Gnomemodule is probably using intltool. Of course, all this means is that these tools will need toprovide whatever it is one provides for scons to do the sametricks. And that's probably a good thing anyway, because itopens the door for other packages to use scons, even if our core packages don't.So, I suppose I should go learn scons so I can provide sconslove in gnome-doc-utils. It was on my agenda anyway, justnot very high on the priority list.--Shaun ___desktop-devel-list mailing listdesktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: autotools gives autopain
On Fri, 2005-12-16 at 17:23 +0100, BJörn Lindqvist wrote: > (Sorry for the inflammatory subject, it is meant to be > humoristic. Although it's true :)) > > Gnome currently uses the GNU Autotools for building all > projects. Autotools is hard to work with and complicated and there are > lots of techically superior build systems out there. Therefore, I > suggest that GNOME should gradually replace Autotools with scons > (www.scons.org). My arguments are: > > 1. Scons is simply technically superior to GNU Autotools - with a big >margin. > > 2. Scons is simple to learn, Autotools is not. > > 3. KDE has already migrated to scons. > > I suggest people give scons a try and it will become apparent how good > scons is (and how bad autotools is). Now my counter-arguments to the > counter-arguments I'm sure people will come up with: [snip some good counter-arguments] One thing we have to consider is that a few modules provide build utilities for other modules to use: intltool, gtk-doc, and gnome-doc-utils are a few. Pretty much anything that provides a library probably uses gtk-doc. Anything providing user help should use gnome-doc-utils. And almost every Gnome module is probably using intltool. Of course, all this means is that these tools will need to provide whatever it is one provides for scons to do the same tricks. And that's probably a good thing anyway, because it opens the door for other packages to use scons, even if our core packages don't. So, I suppose I should go learn scons so I can provide scons love in gnome-doc-utils. It was on my agenda anyway, just not very high on the priority list. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: autotools gives autopain
fre, 16,.12.2005 kl. 18.13 +0100, skrev BJörn Lindqvist: > > > Gnome currently uses the GNU Autotools for building all projects. > > > Autotools is hard to work with and complicated and there are lots of > > > techically superior build systems out there. Therefore, I suggest that > > > GNOME should gradually replace Autotools with scons (www.scons.org). > > > > I'd suggest that this would not be a very interesting topic of discussion on > > this list *unless* you converted one of the existing GNOME modules to scons > > Right. That's the easy part. Any GNOME modules wanna sign up for a > FREE conversion to scons? Limited supply, order now! > How about gnome-hello? It's supposed to be the template for any gnome module... Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: autotools gives autopain
> > Gnome currently uses the GNU Autotools for building all projects. > > Autotools is hard to work with and complicated and there are lots of > > techically superior build systems out there. Therefore, I suggest that > > GNOME should gradually replace Autotools with scons (www.scons.org). > > I'd suggest that this would not be a very interesting topic of discussion on > this list *unless* you converted one of the existing GNOME modules to scons Right. That's the easy part. Any GNOME modules wanna sign up for a FREE conversion to scons? Limited supply, order now! > and demonstrated its benefits to developers, distributors and users of GNOME > (who care about building it from revision control or tarballs). That'll be a That is the hard part. You can't demonstrate the benefit without getting them to try it and you can't get them to try it without demonstrating the benefit. Moment 22. > great starting point for a discussion, while arguing theoretical stuff won't > really get us anywhere. :-) Agreed. I'll come back with a demo. Atleast it is good to know that the door isn't "slammed shut" for migrating to another build system. -- mvh Björn ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: autotools gives autopain
BJörn Lindqvist wrote: (Sorry for the inflammatory subject, it is meant to be humoristic. Although it's true :)) Gnome currently uses the GNU Autotools for building all projects. Autotools is hard to work with and complicated and there are lots of techically superior build systems out there. Therefore, I suggest that GNOME should gradually replace Autotools with scons (www.scons.org). My arguments are: 1. Scons is simply technically superior to GNU Autotools - with a big margin. 2. Scons is simple to learn, Autotools is not. 3. KDE has already migrated to scons. I suggest people give scons a try and it will become apparent how good scons is (and how bad autotools is). Now my counter-arguments to the counter-arguments I'm sure people will come up with: 1. Autotools have worked so far, why switch? - Because scons is easier and better. In the long run the benefits of a good build system outweighs the disadvantages of switching to it. 2. Autotools supports a huge number of platforms. - scons does too. Albeit maybe not as many. But it will, if major projects like GNOME adopts it. 3. Autotools have been a standard tool for over a decade. Scons is new and have not gone through the rigorous testing and enhancement Autotools has. - That is true, but if everyone used that logic nothing would ever change because everyone would stick to the proven and true. Besides, if KDE dares to switch, why wouldn't GNOME? http://dot.kde.org/1126452494/ 4. Wouldn't this make building GNOME depend on Python? For some reason I can't/don't wanna install Python. - Yes. But every modern Linux distro comes with Python pre-installed. And if it isn't installed, installing it manually should be easy enough. If your system is so ancient that Python won't install, then odds are that GNOME won't compile either. Besides why would you wan't the latest and greatest GNOME on such an old machine? 5. The migration to SCons will be really painful. - Let's look at how KDE managed and learn from them. No change is without a price, but going from autotools to scons is worth it. I imagine that the transition can happen gradually and that the old build system will be retained for a while then deprecated and finally removed. 6. I'm not a big fan of Python... - Then try it. :) If you still are not a fan of Python then please realise that there are many more fans of Python than there are fans of the m4/POSIX sh/make language combination... I hope my arguments are very convincing and not inflammatory. Let's get some good discussion going. -- mvh Björn ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list Sounds really nice, I have noticed more projects have started to use scons, and I have always had problems setting up autotools.. I will definetly try it out with whatever next thing i try to make. - gaute ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: autotools gives autopain
> Gnome currently uses the GNU Autotools for building all projects. > Autotools is hard to work with and complicated and there are lots of > techically superior build systems out there. Therefore, I suggest that > GNOME should gradually replace Autotools with scons (www.scons.org). I'd suggest that this would not be a very interesting topic of discussion on this list *unless* you converted one of the existing GNOME modules to scons and demonstrated its benefits to developers, distributors and users of GNOME (who care about building it from revision control or tarballs). That'll be a great starting point for a discussion, while arguing theoretical stuff won't really get us anywhere. :-) Thanks! - Jeff (who has heard lots of nice things about scons from friends who use it all the time) -- linux.conf.au 2006: Dunedin, New Zealand http://linux.conf.au/ No match for "LINUSWEARSTHEPANTS.ORG". ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
autotools gives autopain
(Sorry for the inflammatory subject, it is meant to be humoristic. Although it's true :)) Gnome currently uses the GNU Autotools for building all projects. Autotools is hard to work with and complicated and there are lots of techically superior build systems out there. Therefore, I suggest that GNOME should gradually replace Autotools with scons (www.scons.org). My arguments are: 1. Scons is simply technically superior to GNU Autotools - with a big margin. 2. Scons is simple to learn, Autotools is not. 3. KDE has already migrated to scons. I suggest people give scons a try and it will become apparent how good scons is (and how bad autotools is). Now my counter-arguments to the counter-arguments I'm sure people will come up with: 1. Autotools have worked so far, why switch? - Because scons is easier and better. In the long run the benefits of a good build system outweighs the disadvantages of switching to it. 2. Autotools supports a huge number of platforms. - scons does too. Albeit maybe not as many. But it will, if major projects like GNOME adopts it. 3. Autotools have been a standard tool for over a decade. Scons is new and have not gone through the rigorous testing and enhancement Autotools has. - That is true, but if everyone used that logic nothing would ever change because everyone would stick to the proven and true. Besides, if KDE dares to switch, why wouldn't GNOME? http://dot.kde.org/1126452494/ 4. Wouldn't this make building GNOME depend on Python? For some reason I can't/don't wanna install Python. - Yes. But every modern Linux distro comes with Python pre-installed. And if it isn't installed, installing it manually should be easy enough. If your system is so ancient that Python won't install, then odds are that GNOME won't compile either. Besides why would you wan't the latest and greatest GNOME on such an old machine? 5. The migration to SCons will be really painful. - Let's look at how KDE managed and learn from them. No change is without a price, but going from autotools to scons is worth it. I imagine that the transition can happen gradually and that the old build system will be retained for a while then deprecated and finally removed. 6. I'm not a big fan of Python... - Then try it. :) If you still are not a fan of Python then please realise that there are many more fans of Python than there are fans of the m4/POSIX sh/make language combination... I hope my arguments are very convincing and not inflammatory. Let's get some good discussion going. -- mvh Björn ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
