Skip to content
⌘ NSIS Forum Archive

Big rant: Unusable build system

7 posts

CodeSquid#

Big rant: Unusable build system

Sorry if I'm bit overreacting, but I have to say this.

Every single time I want to update NSIS on my Debian server, I have extreme problems. And somehow this time I can't figure out how to solve it. It's so damn annoying, isn't a build system supposed to make this easy?

Instead of just doing a simple scons, it complained about some ridiculous things like CPPPATH and LIBPATH not found. Isn't a good build system supposed to find this out on itself?

Anyhow, I'm using this overly complex, totally confusing command:
scons PREFIX="/home/nightlybuild/NSIS" CPPPATH="." LIBPATH=. CODESIGNER=. SKIPSTUBS=all SKIPPLUGINS=all SKIPUTILS=all SKIPMISC=all
But guess what my reward is:
TypeError: Action() got an unexpected keyword argument 'generator':

  File "SConstruct", line 186:

    envs = SConscript('SCons/Config/gnu')

  File "/usr/lib/python2.2/site-packages/SCons/Script/SConscript.py", line 581:

    return apply(method, args, kw)

  File "/usr/lib/python2.2/site-packages/SCons/Script/SConscript.py", line 508:

    return apply(_SConscript, [self.fs,] + files, {'exports' : exports})

  File "/usr/lib/python2.2/site-packages/SCons/Script/SConscript.py", line 239:

    exec _file_ in stack[-1].globals

  File "SCons/Config/gnu", line 39:

    cross_env(stub_env)

  File "SCons/Config/gnu", line 11:

    env.Tool('crossmingw', toolpath = ['../Tools'])

  File "/usr/lib/python2.2/site-packages/SCons/Environment.py", line 906:

    return SCons.Tool.Tool(tool, map(self.subst, toolpath))(self)

  File "/usr/lib/python2.2/site-packages/SCons/Tool/__init__.py", line 64:

    module = imp.load_module(name, file, path, desc)

  File "../Tools/crossmingw.py", line 107:

    None
Isn't that great? I really wonder why noone ever thought about using the simple, never failing autoconf/automake build system, but instead this useless SCons is used.
Even hand-crafted makefiles seem to be more portable.
kichik#
Yes, you are overreacting. All you need to do, is open up INSTALL and see SCons 0.96.91 and above is required. It's also listed in the SConstruct file itself. Speaking of which, how did you get past EnsureSConsVersion?

Also, if you're using Debian, you can use pabs' .deb package. The latest version is always in the experimental branch. 2.10 was accepted a day after it was released.

Now as for autotools being better, read these:I tried to find some articles describing SCons weaknesses, but couldn't find any. Though not because they don't exist. Here's a short list of things I can think of:
  • It's still in development (as you've noticed)
  • It's not that fast, but they're working on it
  • Some error messages aren't that user friendly, especially those with a stack trace (again, working on it)
CodeSquid#
Originally posted by kichik
[B]Yes, you are overreacting. All you need to do, is open up INSTALL and see SCons 0.96.91 and above is required. It's also listed in the SConstruct file itself. Speaking of which, how did you get past EnsureSConsVersion?
Well, I checked scons version I had installed, was too old. So I went to scons.org and downloaded the debian package. There I made a fatal mistake and didn't notice that I downloaded and installed the 'stable' version which was 0.96.1. 🙄
When I ran scons it didn't complain about outdated version, it told me some syntax error, argument number mismatch or so. Not quite what a version check should do. So I commented that check out.

Also, if you're using Debian, you can use pabs' .deb package. The latest version is always in the experimental branch. 2.10 was accepted a day after it was released.
Ah, thanks for pointing that out, didn't know there was even an experimental branch. Only tried unstable and testing. Whats the point of 4 branches anyhow if unstable and testing have the same ancient version as stable.

Now as for autotools being better, read these:
The third article was linked on Slashdot some time ago I think, did read it before. Wasn't really convinced by it. Especially one sentence made me laugh: "Makefiles lack support for complex dependencies [...}"

Sorry again for overreacting. Actually with proper scons version it works as it's supposed to be, although it's very verbose due to lots of defines. A config.h would solve this, but that's not a good solution according to that article on freshmeat 😉
kichik#
The TypeError is raised because in older version of SCons, EnsureSConsVersion accepted only two arguments for major and minor version. Only 0.96.91 and above accepts the revision argument. I thought that whoever would dare editing SConstruct, would easily figure out a new version is required. But I guess it's better to just spell it out. I've even said this is a bad thing in the above post. I've added a try-catch block in CVS to spit out a nicer error message. It's not as elegant as the old check, but I'll survive.

I don't know what that article meant by that quote, but I certainly like SCons' way of handling dependencies. No need for a separate call to `make depend` after every inclusion change.

I've moved most of the configuration from config.h into the build system, because it's much more comfortable to use that way. It's especially useful for my release script. It's possible to have it write the defines to the old config.h, which is still used, but there's no good enough reason for that.
CodeSquid#
Originally posted by kichik
I've added a try-catch block in CVS to spit out a nicer error message. It's not as elegant as the old check, but I'll survive.
Thanks for your effort.

I don't know what that article meant by that quote, but I certainly like SCons' way of handling dependencies. No need for a separate call to `make depend` after every inclusion change.
Never seen `make depend` myself. At least using automake there is no 'depend' target. A simple call to make is all that is needed, even the Makefiles get remade if a Makefile.am changes. Sure autoconf/make and the likes have its problems, but nowhere as bad as that article claims.

I've moved most of the configuration from config.h into the build system, because it's much more comfortable to use that way. It's especially useful for my release script. It's possible to have it write the defines to the old config.h, which is still used, but there's no good enough reason for that.
Yes, moving it to the build system was the right decision. But the way it's now, passing every define using compiler switches generates a lot of redundant output in the build log, making it easy to miss things like warnings. And it slows down build time a little bit, especially if compiling in a SSH shell over a low bandwidth connection on a remote machine. But that's not that important, I'm sure you've better things to do than making the build log looking pretty.
kichik#
Originally posted by CodeSquid
Never seen `make depend` myself. At least using automake there is no 'depend' target. A simple call to make is all that is needed, even the Makefiles get remade if a Makefile.am changes. Sure autoconf/make and the likes have its problems, but nowhere as bad as that article claims.
`depend` is the standard name for a target that calls makedepend. It parses C files to find header file dependencies and writes them to the Makefile. Without it, a change to a header file goes undetected by the Makefile. This kind of a situation usually causes weird crashes. It causes different C files to be compiled with different versions of the same header files. On top of the time you'd waste trying to figure out the problem, comes the solution, `make clean && make all`, which wastes even more of your time.
And it slows down build time a little bit, especially if compiling in a SSH shell over a low bandwidth connection on a remote machine.
Why not redirect the output to a file?

BTW, I've tried checking how header dependencies are handled in your package, but http://filezilla.sourceforge.net/FZ3-autotools.tar.bz2 is empty and my Debian only has automake-1.4.
pabs#
About debian experimental, nsis is only there because the scons maintainer didn't want to upload a pre-release version to unstable, but he was fine with uploading it to experimental.

As soon as scons is released, I'll be able to update the version in unstable/testing, and upload a package for sarge to backports.org (if it supports sarge by then).