Build script should allow choice of compiler

[WebDrake]

If I understand correctly, the current build script hardcodes in dmd as the compiler. This is undesirable for a couple of reasons.

• gdc produces much faster code, so if you're in a position to compile with gdc this is preferable :-)
• Some Linux distros (e.g. Debian) have strict rules about proprietary dependencies; a reliance on dmd will block packaging of SciD. Of course, it's trivial to manually tweak the build script, but nicer to make it so they don't have to.
• ... related: it's not clear to me that the build script allows you to set optimization flags. This would be nice to have as well.

[kyllingstad]

I agree, the build script is pretty limited right now. Keep in mind, when I wrote it, the other D2 compilers weren't even close to being up-to-date with the language. I am currently working on a better build system, which will allow the use of any compiler, provide full flexibility in setting compiler options, and so on. This is going a bit slowly, though, so don't hold your breath. ;-)

Note that the library itself is straightforwardly compiled by hand. There are no quirks or special considerations that I am aware of. Using DMD (any other compiler should be similar), just issue the following command in the root directory of the repository:

dmd -lib -oflibscid.a `find scid | grep '\.d$'`

The main benefit of using the build script is auto-generation of headers (which aren't really necessary; just use the full source code) and CandyDoc documentation.

[WebDrake]

Not intended as a deep critique, just to make sure the question was raised :-)

Re using the full source code: I think this is actually what's done also with Phobos packages in Linux distro repositories, at least for Debian/Ubuntu; there's no compiled libphobos at all.

[kyllingstad]

Re using the full source code: I think this is actually what's done also with Phobos [...]

The main reason for this is that header generation has historically been very buggy in DMD. I believe many (maybe all?) of the problems have been fixed in recent releases, however.

[WebDrake]

Back to the build script: forgetting the choice of compiler called within the script, there's some problem related to running it as a script with gdmd.

gdmd -run build.d

generates an error: Unknown command: -I/usr/include/d/dmd/phobos. Using gdmd -run build.d lib (or headers) works fine for those options, so it's a failure of the opening if statement.

In fact, if you include a couple of lines at the beginning of the main function,

writeln("Number of arguments: ",args.length);
foreach(string a; args)
    writeln("\t",a);

... you find that gdmd translates to a rather extensively-optioned form that clearly causes that if statement to choke:

Number of arguments: 7
/home/joseph/code/SciD/build
-I/usr/include/d/dmd/phobos
-I/usr/include/d/dmd/druntime/import
-L-L/usr/lib
-L-L/usr/lib32
-L--no-warn-search-mismatch
-L--export-dynamic

Using std.getopt with --lib, --headers, etc. is probably a better way to determine what to build. If you think it'll be useful I'll try and prepare a patch to that end.

[kyllingstad]

I disagree. To me it seems that the problem is with gdmd, and not the build script. Does the following work for you?

gdmd build.d && ./build

If so, I'll add a notice to that effect in the README and on the wiki.

[WebDrake]

Yes, it runs fine if you compile it first. Adding those instructions to README and wiki is probably a good idea.

Agree that gdmd has a problem here, but still think that the way you handle build arguments is problematic.

[WebDrake]

I've added a bug report for GDC on this point: https://bitbucket.org/goshawk/gdc/issue/335/gdmd-run-interferes-with-program-arguments

[kyllingstad]

Agree that gdmd has a problem here, but still think that the way you handle build arguments is problematic.

Could you explain why it is problematic? It looks at the first command line argument for a build target, and builds that target. If no target is specified, it assumes the user wants to build the library file and the headers. If you pass it an argument it doesn't recognise, it terminates gracefully with an error message. I don't think a simple build script should be expected to recover from invalid user input.

One simple improvement that could be made, however, is to pass anything past that first argument, i.e. args[2..$], straight on to the compiler. That would be a temporary solution for your request for being able to specify optimisation flags, because then you could do e.g.

./build lib -release -inline -O

I've added a bug report for GDC on this point

Great, thanks!

[kyllingstad]

Done: kyllingstad@45569e9

[WebDrake]

Agree, I was being harsh on what is a simple build script. Put simply my thought was for the bigger picture and a build script that would carefully check all arguments. Anyway, your fix looks nice :-)

[kyllingstad]

Fixed a long time ago, just forgot to close it then.