As a parent of an encephalopathic child (so-called "Austism spectrum") you come into contact with a lot of crazies. There's a "theory" put forward by a father/son duo of scientists-cum-professional-witnesses that Autism is linked to mercury preservatives in vaccines. Robert F. Kennedy Jr. until recently evangelized this point of view, saying that big pharma is part of some sort of conspiracy to harm your children. RFK has since divorced himself from this viewpoint, and the "scientists" have had their funding yanked. Not to mention, the preservative has not been part of vaccines in the US since circa 2001.
But parents, particularly those with at least one Autistic child, are not vaccinating their kids. If you tell them that the mercury preservative is gone, they'll tell you they have "heard of this time that someone's doctor lied to them." So many parents are opting to take on the very real danger of these deadly diseases in favor of the smoke and mirrors about Autism.
Oh, and both my kids have been vaccinated.
I still think Java is a questionable choice because in that configuration it does not bring to the table anything that Python, PHP or Perl would, but that is not my worry.
It's funny that most of the complaints I hear from naive users of Java programs tend to be for GUI applications. Some VMs still don't run GUI (swing and so forth) properly, and I have seen huge differences in perceived "quality" of an applications just by upgrading VMs. You guys are blaming the shortcomings of a VM implementation on a language. And yes, VM technology for GUI apps has lagged a couple years behind server side apps, and with good reason...most application software is still written in C/C++, largely because it's based on some legacy code.
Anyway I'll give you the benefit of the doubt that your remark was not a troll, because server side apps is where Java unequavocally shines. Anyone who says Perl, PHP, or Python (i.e., 2-tier CGI type) architectures can hang with the likes of J2EE is instantly labelling themselves as someone who's done exactly zero server side development for anything but the most trivial of web applications. So back away from the server side commentary before you lose what little credibility was left after I read your nick:)
But don't denounce the language or the environment. Rather, we should demand better VM support for GUI applications as well. I do 95% of my professional development in C++ and even though a lot of code is more concise and "pretty" in C++ than Java, C++ (particularly in embedded applications) is horribly costly and difficult to debug due to its lack of any sort of runtime environment. And yes you pay some bloat for the runtime environment, but it's already gotten to the point in server apps where processor power is cheaper than developer time, and it's headed that way in the embedded space as well.
Yes, no-op build time is one thing we continually optimize for. Believe it or not, it's about 50x faster than it was at our initial release:)
Also, there are several things you can do to sacrifice potential build correctness in order to speed up no-op build time, which are documented in the SCons Wiki. Unfortunately the Wiki appears to be on the fritz right now.
Our philosophy is that, by default, we provide an absolutely correct build, which means recalculating/rescanning a lot of stuff every time -- the equivalent of doing a make depends;make every time (I venture that our no-op build time is faster than that!). However, if you know that you have not changed certain things, you can keep SCons from rescanning them, which is great for when you are in the compile/fix/recompile mode. I usually have an alias for "fast, not-so-accurate SCons" that I use for development and "accurate SCons" that I use for testing and release.
Finally, there is a separate effort toi "daemonize" SCons. SCons has an as-yet-unpublished API that allows Python developers to put other wrappers around it other than the SConscript (i.e., makefiles-in-Python) interface that ships with it. The daemon effort keeps SCons around and rescans dependencies in the background a'la MS DevStudio, saving lots of time during the build. I believe the people on this project have seen as much as a 100x performance increase for no-op build times for large projects. Amazingly, it looks like we don't have a link to this on our page. I'll try to dig it up.
Built-in support means you generally don't have to write rules (or "Builders" as they are called on SCons parlance) for these tools. SCons allows you to write your own Builders, which can range from very simple to very complex depending on the needs of the tool, to work with just about any tool chain you need. So, "built-in" simply means you don't have to extend SCons at all to use it, and also migth have other implications such as being able to automatically generate dependencies for certain file types, like figuring out what header files a C file depends on.
As far as a comparison to Ant, in my experience Ant is great for building Java projects, but a little bit of a pain to get to work with C++. Also, it must be extended in Java, which is a little less weildy than a scripting language. The one-line comparison is SCons's Java support lags behind Ant currently, but I prefer SCons for just about everything else.
As a developer of SCons, I'd like to address the "annoyances" above:
"Unless you don't know Python. I never figured make syntax to be very difficult."
Neither is Python, and Python is much more powerful. I've seen makefiles for complex build processes, and they are nigh unreadable. Even if you don't know Python already, we considered the choice of a well-established, actively developed, powerful scripting language to be superior to the invention of Yet Another Mini Language.
"I didn't realize this was an improvement over make, which is pretty language-agnostic. What about other languages? I usually assume listing specific elements means unlisted elements are NOT supported."
You know what they say about assuming... I'll stipulate that the exact meaning of this statement is unclear at first glance. However, consider one of SCons's other features...automated dependency generation. In order to do that, SCons must have a dependency generator for that particular language (to parse #include's, etc.) Users can add their own dependency generators as well. SCons *will* support any language just like make, as long as you can put up with specifying dependencies explicitly for "unsupported" languages, just like make.
SCons also makes it much easier than make to set up builds, since it already has some built-in knowledge of the way certain tools work. All of this is of course user-extensible, but we provide built-in support for some common tools.
"That -j option look like they borrowed it from make"
Okay, yes, we did borrow that from make.
"Not sure exactly what this means, but make understands RCS and SCCS, IIRC. Been a while since I used the feature"
SCons does not integrate with a specific source control system, but it does allow you to specify multiple directories (repositories) that will be searched for files before they are built or taken from the host machine. This allows building from a server, or even multiple servers. I think this is akin to make's "VPATH" support, but AFAIK it is more flexible.
Come and see SCons and judge for yourself. I find it alredy vastly superior to make for large-scale, highly variant projects (or any project!) Of course, I am biased, since I wrote a large part of it, but I did so because I found existing tools insufficient.
Slashdot Mirror
As a parent of an encephalopathic child (so-called "Austism spectrum") you come into contact with a lot of crazies. There's a "theory" put forward by a father/son duo of scientists-cum-professional-witnesses that Autism is linked to mercury preservatives in vaccines. Robert F. Kennedy Jr. until recently evangelized this point of view, saying that big pharma is part of some sort of conspiracy to harm your children. RFK has since divorced himself from this viewpoint, and the "scientists" have had their funding yanked. Not to mention, the preservative has not been part of vaccines in the US since circa 2001. But parents, particularly those with at least one Autistic child, are not vaccinating their kids. If you tell them that the mercury preservative is gone, they'll tell you they have "heard of this time that someone's doctor lied to them." So many parents are opting to take on the very real danger of these deadly diseases in favor of the smoke and mirrors about Autism. Oh, and both my kids have been vaccinated.
I still think Java is a questionable choice because in that configuration it does not bring to the table anything that Python, PHP or Perl would, but that is not my worry. It's funny that most of the complaints I hear from naive users of Java programs tend to be for GUI applications. Some VMs still don't run GUI (swing and so forth) properly, and I have seen huge differences in perceived "quality" of an applications just by upgrading VMs. You guys are blaming the shortcomings of a VM implementation on a language. And yes, VM technology for GUI apps has lagged a couple years behind server side apps, and with good reason...most application software is still written in C/C++, largely because it's based on some legacy code. Anyway I'll give you the benefit of the doubt that your remark was not a troll, because server side apps is where Java unequavocally shines. Anyone who says Perl, PHP, or Python (i.e., 2-tier CGI type) architectures can hang with the likes of J2EE is instantly labelling themselves as someone who's done exactly zero server side development for anything but the most trivial of web applications. So back away from the server side commentary before you lose what little credibility was left after I read your nick :)
But don't denounce the language or the environment. Rather, we should demand better VM support for GUI applications as well. I do 95% of my professional development in C++ and even though a lot of code is more concise and "pretty" in C++ than Java, C++ (particularly in embedded applications) is horribly costly and difficult to debug due to its lack of any sort of runtime environment. And yes you pay some bloat for the runtime environment, but it's already gotten to the point in server apps where processor power is cheaper than developer time, and it's headed that way in the embedded space as well.
(SCons developer here)
Yes, no-op build time is one thing we continually optimize for. Believe it or not, it's about 50x faster than it was at our initial release :)
Also, there are several things you can do to sacrifice potential build correctness in order to speed up no-op build time, which are documented in the SCons Wiki. Unfortunately the Wiki appears to be on the fritz right now.
Our philosophy is that, by default, we provide an absolutely correct build, which means recalculating/rescanning a lot of stuff every time -- the equivalent of doing a make depends;make every time (I venture that our no-op build time is faster than that!). However, if you know that you have not changed certain things, you can keep SCons from rescanning them, which is great for when you are in the compile/fix/recompile mode. I usually have an alias for "fast, not-so-accurate SCons" that I use for development and "accurate SCons" that I use for testing and release.
Finally, there is a separate effort toi "daemonize" SCons. SCons has an as-yet-unpublished API that allows Python developers to put other wrappers around it other than the SConscript (i.e., makefiles-in-Python) interface that ships with it. The daemon effort keeps SCons around and rescans dependencies in the background a'la MS DevStudio, saving lots of time during the build. I believe the people on this project have seen as much as a 100x performance increase for no-op build times for large projects. Amazingly, it looks like we don't have a link to this on our page. I'll try to dig it up.
Built-in support means you generally don't have to write rules (or "Builders" as they are called on SCons parlance) for these tools. SCons allows you to write your own Builders, which can range from very simple to very complex depending on the needs of the tool, to work with just about any tool chain you need. So, "built-in" simply means you don't have to extend SCons at all to use it, and also migth have other implications such as being able to automatically generate dependencies for certain file types, like figuring out what header files a C file depends on. As far as a comparison to Ant, in my experience Ant is great for building Java projects, but a little bit of a pain to get to work with C++. Also, it must be extended in Java, which is a little less weildy than a scripting language. The one-line comparison is SCons's Java support lags behind Ant currently, but I prefer SCons for just about everything else.
As a developer of SCons, I'd like to address the "annoyances" above:
"Unless you don't know Python. I never figured make syntax to be very difficult."
Neither is Python, and Python is much more powerful. I've seen makefiles for complex build processes, and they are nigh unreadable. Even if you don't know Python already, we considered the choice of a well-established, actively developed, powerful scripting language to be superior to the invention of Yet Another Mini Language.
"I didn't realize this was an improvement over make, which is pretty language-agnostic. What about other languages? I usually assume listing specific elements means unlisted elements are NOT supported."
You know what they say about assuming... I'll stipulate that the exact meaning of this statement is unclear at first glance. However, consider one of SCons's other features...automated dependency generation. In order to do that, SCons must have a dependency generator for that particular language (to parse #include's, etc.) Users can add their own dependency generators as well. SCons *will* support any language just like make, as long as you can put up with specifying dependencies explicitly for "unsupported" languages, just like make.
SCons also makes it much easier than make to set up builds, since it already has some built-in knowledge of the way certain tools work. All of this is of course user-extensible, but we provide built-in support for some common tools.
"That -j option look like they borrowed it from make"
Okay, yes, we did borrow that from make.
"Not sure exactly what this means, but make understands RCS and SCCS, IIRC. Been a while since I used the feature"
SCons does not integrate with a specific source control system, but it does allow you to specify multiple directories (repositories) that will be searched for files before they are built or taken from the host machine. This allows building from a server, or even multiple servers. I think this is akin to make's "VPATH" support, but AFAIK it is more flexible.
Come and see SCons and judge for yourself. I find it alredy vastly superior to make for large-scale, highly variant projects (or any project!) Of course, I am biased, since I wrote a large part of it, but I did so because I found existing tools insufficient.
www.scons.org