On Sun, 2016-11-27 at 12:42 -0800, Bill Deegan wrote: > Andrew, > > If it's interesting to you, go ahead and work on it! > There's an index of community supported builders in the wiki. Feel > free to > add your work there (https://bitbucket.org/scons/scons/wiki/ToolsInde > x). > Or if you like add it to here: https://bitbucket.org/scons/scons-cont > rib >
This raises the issue of whether we should be thinking about active curation of the Contrib repository, and how to manage it. Currently having the individual repository per tool, it is easy to clone the repositories to ~/.scons/site_scons/site_tools or <project>/site_scons/site_tools and things just work. hg/git/bzr as management tools have many positive aspects, and a few negative ones, over any using pip. The Contrib repository appears to have to be installed, presumably using setuptools or pip. This is not yet a package on PyPI, so it cannot be pip-ed in via download, you have to have the hg clone. And then there is the issue that anyone using a platform with package management should never use pip into the package managed area – always use pip --user. Also it seems that each individual tool in Contrib has to have a separate installation record, which will be a management nightmare without automation. So this raises a number of issues. 1. What is the purpose, aim, and goal of the Contrib repository? 2. Is it intended as the place where things will be migrated out of the SCons core distribution? 3. Should it deploy into the running SCons installation or to a site_scons/site_tools? 4. Is it just for tools? 5. Should SCons support not-tool add-ins better? 6. What is the process for adding things to Contrib? 7. What is the mechanism for removing things from Contrib? 8. Is it feasible to move the C, C++, Fortran, D stuff out of the core without a total rewrite of the core? 9. Is anyone thinking about how to do C++ builds with SCons in the presence of package managers such as Conan. In a sense I feel a bit of a fraud contributing here just now. Apart from LaTeX builds, and a few small pet projects, I am hardly using SCons just now. CLion (*) required CMake as the build tool, so most of the C and C++ projects I workl on use CMake, and the other C and C++ projects I am associated with use Autotools :-( or are moving to Meson. D, Rust, Go, all have their own build systems, and the Kotlin, Groovy, Ceylon, Scala, Clojure, Java, i.e. JVM-based languages either use Gradle (or Maven) or have their own build frameworks (sbt, lein,…) Having said this, having shoved hard at the Python 3 compatibility for SCons and the tools as repositories with a central index, I feel a responsibility to see these through to some form of conclusion, even though I am using SCons less and less. -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:[email protected] 41 Buckmaster Road m: +44 7770 465 077 xmpp: [email protected] London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Scons-dev mailing list [email protected] https://pairlist2.pair.net/mailman/listinfo/scons-dev
