>>* Revamp platform/toolchain - Right now it's left to the user to implement >>logic to say, if I have these 3 tools, then use all of them, otherwise use >>these tools. Think mingw vs msvc on win32 for example
I have something for this in Parts. It could be improved on however. >>* Add support for components - For example a library can specify what include >>paths, defines, libraries, compiler flags would be used by programs (or >>components) which use itself. Parts provides some of this I beleive. I >>would want this as an available API, but not mandatory to use SCons I agree. I do think I have something here. It is very useful. My view is that this should be an optional thing. * Handle pulling components from repos.. cmake,gradle, etc can do this, I think it's pretty darn useful especially where you may have a project with many repos and you focus on just one. I think there are two ways to view this. 1. I have in Parts VCS objects that allow checking out “components” form different locations. Given they use Parts it is easy to build the code. However the reality of this is that the code is using a different build system. One item I always had to do in Parts was to make a “part(…)” call have some notion of a build type. So I could checkout some component and call the build system they used to get the code to build. I had viewed this as a library feature in which one could define a repo of wrapper parts that would allow a user to get the code, or maybe some package to build against based on the system and target you are building for. 2. Use some other system to do this. Conan seems to be the best option from what I have seen as they have most of this already working. It would be about integrating with the system better. They are big SCons fans, so I see it as win-win. Autoconf… I am trying to improve my imple of the Settings object in Parts ( based on Greg Noels IAPAT notes). I am currently busy with other items, but have been trying to make progress at porting Apache Trafficserver to use SCons and Parts. Given this code uses the configure logic heavily, it is a great test case. I am trying to see if there is a better way we can define this logic in the Parts Setting object to do the configure stuff without the “coding” issues that can cause slow down or utter maintainer nightmares or updating it or understanding it. Jason From: Scons-dev [mailto:[email protected]] On Behalf Of Bill Deegan Sent: Thursday, July 27, 2017 10:57 AM To: SCons developer list <[email protected]> Subject: Re: [Scons-dev] SCons performance investigations Russel, You're forgetting (I think) that SCons does implement (some) of AutoConf/AutoMake's functionality. Could it be better/more complete? Of course. Is it usable (and used)? very much so. Here's how I see the next two releases: 3.0 - PY2/3 compat, VS 2017, some minor performance improvements. Post 3.0 - Migrate to GitHub 3.1 - Focus on performance. I think (per the email/wiki page), there's lots of opportunities to speed up SCons, without losing it's SCons'ness.. (If we swap out sconsign implementations we will need to have the version string be 4.0 as we're breaking compatibility) Of course everything depends on how much time/effort the community (and myself) are able to provide towards improving SCons. Things I'd really like to see happen in the not too distant future: * Revamp platform/toolchain - Right now it's left to the user to implement logic to say, if I have these 3 tools, then use all of them, otherwise use these tools. Think mingw vs msvc on win32 for example * Add support for components - For example a library can specify what include paths, defines, libraries, compiler flags would be used by programs (or components) which use itself. Parts provides some of this I beleive. I would want this as an available API, but not mandatory to use SCons * Handle pulling components from repos.. cmake,gradle, etc can do this, I think it's pretty darn useful especially where you may have a project with many repos and you focus on just one. * Taskmaster improvements (see the need for speed wiki page, and also comments by Jason about Greg Noel's TaskmasterNG which Greg (who's long since left the project worked on, but never contributed, or shared sources with anyone). Most of these bullets are in the nice to have. I think improving performance is in the must have as it's the top complaint I hear about SCons. -Bill On Thu, Jul 27, 2017 at 4:22 AM, Russel Winder <[email protected]<mailto:[email protected]>> wrote: On Tue, 2017-07-25 at 20:07 +0000, Jason Kenny wrote: > > > […] > Scons, make, ninja, msbuild are items to compare. The idea of comparing > CMake, Meson or autotools to SCons in incorrect. There is a big difference > in a "generator" and a build system and a build manager (ie stuff like > buildbot). I keep hearing how CMake is taking off and everyone is moving to > it.... which is really saying it is better cross platform build file > generator than automake. SCons slightly bridges the gap between Make, Ninja, Tup on the one hand and CMake and Meson on the other – I have no experience of all the Windows stuff. Certainly CMake, and Meson, are getting increased traction in the native build space, though Autotools and Make have a huge "install base". There is also Bazel, Gradle, a whole host of build systems. I notice an increasing number of people complaining about the CMake specification language. Meson implements a DSL on Python rather than using Python which is sometimes annoying – but you can hack and execute code if need be. SCons is caught in the middle a bit having started purely as a Make replacement and not keeping up with Ninja and Tup in build performance and not keeping up with Autotools, Meson, Reggae, and CMake of being meta build systems. We should also not ignore all the language specific package handling and build systems such as Cargo, Dub, and Gradle. I guess the core question is "Where is SCons going?" Currently for me SCons is the tool for the cases where there isn't another. So for the moment I use SCons always for XeLaTeX builds and sometimes for D builds, otherwise I am no longer using SCons because there is now a better or more appropriate tool for each code base. One of the biggest hurdles is CLion requiring CMake for C++ projects. Another issue is of course the inertia behind people sticking with Make and Autotools. […] -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200<tel:%2B44%2020%207585%202200> voip: sip:[email protected]<mailto:sip%[email protected]> 41 Buckmaster Road m: +44 7770 465 077<tel:%2B44%207770%20465%20077> xmpp: [email protected]<mailto:[email protected]> London SW11 1EN, UK w: www.russel.org.uk<http://www.russel.org.uk> skype: russel_winder _______________________________________________ Scons-dev mailing list [email protected]<mailto:[email protected]> https://pairlist2.pair.net/mailman/listinfo/scons-dev
_______________________________________________ Scons-dev mailing list [email protected] https://pairlist2.pair.net/mailman/listinfo/scons-dev
