Re: autotools gives autopain

[James Henstridge <james jamesh id au>]

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.