On Mon, Apr 10, 2017 at 05:56:38PM +0000, Matthias Klumpp via Digitalmars-d-announce wrote: > On Monday, 10 April 2017 at 15:27:25 UTC, Russel Winder wrote: [...] > > My thought for SCons was to delegate the package fetching to Dub as > > a subprocess or write some Python to use the Dub API. I'm not clear > > on that as yet, the issue is whether the Dub local source repo is > > the right way forward – using Dub for preparing the compiled > > artefact is likely not the right way forward for SCons. This would > > then make it easy to do something for Rust/Cargo – except that SCons > > doesn't really support Rust yet, and with Cargo are there any Rust > > users not using Cargo. > > > > Having said all this SCons stuff, if there was Meson support for > > this "get the source from the Dub repository, compile it and make it > > a dependency" I'd likely stay with Meson for my codes. > > SCons is considered evil, last time I checked ^^ => > https://wiki.debian.org/UpstreamGuide#line867 > (unless it's used right, which seems to be hard) - I have no idea > though on whether the issues with it were fixed, the entry on SCons > hasn't been updated in a while.
I use SCons exclusively for my D projects, and haven't faced any major problems. I understand, however, that from a distro's POV, it can be annoying to work with if you're not familiar with how to patch SConstruct scripts to do what is needed. It's true that unless upstream explicitly supports installation targets, SCons won't do it for you. I do actually maintain a Debian package that uses SCons (well, written by yours truly, so perhaps that's cheating), and I did find that I have to write rules explicitly for supporting installation targets just so it will work properly with Debian's packaging scripts. As for SONAME support (mentioned by the wiki), I'm not sure what the big deal is... isn't it just a matter of passing the right linker flags to the compile command? So either adding something to CFLAGS or LDFLAGS in the construction environment should do the trick. SCons refusing to pick up settings from the user's environment can be annoying to distros, but in return for that, it gives you 100% reproducible (incremental!) builds by default, whereas most Makefiles require you to `make clean` just to be sure, to the point that it has become accepted practice to always "build from clean" because otherwise you just never know. Even Debian's packaging scripts have a `clean` target because of this. But in an SCons-based package, the `clean` target is a one-liner `scons -c`, since SCons knows what targets it has produced and practically guarantees you're back to a clean slate. Even though that's actually unnecessary to produce a good build! (Ironically, leaving the `clean` rule blank causes the packaging scripts to complain because they notice stray files lying around, obviously a feature written with a Makefile mindset because stray files are problematic in Makefile-based projects, but hardly worth attention in an SCons-based project!) T -- Curiosity kills the cat. Moral: don't be the cat.
