Slashdot Mirror


Make Out with SCons

Nice2Cats writes "I stumbled across this and can't find a mention of it here yet: SCons, a stable alternative for the vilified make. Built-in support, they claim, for C, C++, and Java, built-in support for use with SCCS, CVS, and BitKeeper, supports .NET, and works with Linux, *BSD systems, Windows NT, and Mac OS X. I'd love something to would finally get rid of the awkward (no pun intended) make, and having a system based on Python would make it double good. Maybe one of the serious C/C++ programers here could give a verdict on if this is the dragon slayer we've been waiting for."

4 of 77 comments (clear)

  1. Questions by Zach+Garner · · Score: 4, Insightful

    Integrated Autoconf-like support for finding #include files, libraries, functions and typedefs.

    Is SCons viewed as a replacement for Autoconf and Automake, or just a replacement for Make?

    Built in support for...

    What does this mean? Will SCons somehow only work with languages that SCons has built in support for?

    How does SCons compare to Apache's Ant?

    1. Re:Questions by pmz · · Score: 4, Insightful

      The good thing about doing ant conf files in XML, si if they change the format, you can use xsl to transform ALL of your xml to a new format.

      Layers upon layers of complexity. XML, XSL, Java, Ant Schemas...all for compiling a program. My sig is appropriate, here, too. A build system for software should be easy, intuitive, transparent, etc. etc. There has yet to be a replacement for make that has these attributes (makes tab syntax really isn't that big of a deal, either, even though that's what most people latch onto when complaining about it).

      Small shell scripts and makefiles. Is more really necessary to call cc and ld or javac or whatever for each file in a directory tree? The differences among platforms can't be so dire as to require gigantic build automation tools, which introduce more problems than they solve!

    2. Re:Questions by sporty · · Score: 3, Insightful

      Layers upon layers of complexity. XML, XSL, Java, Ant Schemas...all for compiling a program. My sig is appropriate, here, too. A build system for software should be easy, intuitive, transparent, etc. etc. There has yet to be a replacement for make that has these attributes (makes tab syntax really isn't that big of a deal, either, even though that's what most people latch onto when complaining about it).


      Whoahoahoa.. no. Blatantly wrong. If ant 1.0 used one particular XML format, and you upgraded to ant 2.0, to go from an ant 1.0 file to 2.0 file, you'd apply an xsl style sheet ONCE to upgrade it all. Any future XML you write would be in the 2.0 format. Simple as that.


      Small shell scripts and makefiles. Is more really necessary to call cc and ld or javac or whatever for each file in a directory tree? The differences among platforms can't be so dire as to require gigantic build automation tools, which introduce more problems than they solve!


      Bash? csh? sh? tcsh? bash 2.0? Which shell are you suggesting is usable across them all?

      ant is just a program, just like make is. You run it against a config file of a certain format, just like Makefiles have their own format. Ant is no more compicated than make. hell.. you can use the core stuff from ant to run any program across many files, just like make. The targeted tasks are just to make those easier.
      --

      -
      ping -f 255.255.255.255 # if only

    3. Re:Questions by jonadab · · Score: 2, Insightful

      As long as the format is regular, it's pretty trivial to write a
      simple script to do the transformation. XML helps enforce a certain
      amount of regularity, but it's by no means the only regular format.

      Personally, I like XML pretty well in general, and I really like
      what OO.o has done with it in particular.

      I'm less enamored with Java, but that's another thread for another day.

      --
      Cut that out, or I will ship you to Norilsk in a box.