Hello tup-using community! I would like to voice a concern that I have about the direction the open source community is taking regarding build systems.
Almost every single new build system that is gaining any traction is built using an imperative, rather than declarative specification language. Consider: Build systems with DECLARATIVE specification languages: make shake (?) makepp (?) gyp ninja tup (w/Tupfile parser) Build systems with IMPERATIVE Build Systems: CMake Waf SCons tup (w/ lua parser) By their nature, declarative languages are way easier to parse recursively, and export in a new modified syntax (or export to an imperative language). This is not just theoretical; makepp and shake both parse makefiles. With a procedural specification language, it is easy to hammer out a huge pile of (often metaprogrammed) code that is difficult to read, and damn near impossible to parse automatically. This is not just theoretical either! In the case of ROS (Robot Operating System, CMake based), their first build configuration they wrote (called rosbuild) was so bad they pretty much had to start from scratch, implementing another (also CMake based) build configuration (called catkin), forcing breaking changes on all of their users. To see what a mess the upgrade was, see: http://wiki.ros.org/catkin/migrating_from_rosbuild I would argue that if all of ROS had been implemented in a delarative language, the ros developers would have been able to write upgrade scripts that Just Work. It seems to me that the tup-using community is at a bit of a unique crossroads. Tup supports both a (not great, but decent) declarative specification language, and an imperative specification language (the lua parser), and users are left to decide which they will use. I would humbly argue in favor of the following: 1. Users use primarily Tupfiles for new projects for now 2. Users only use imperatve lua as a last resort, akin to the "run" / bash tup metaprogramming hacks 3. Mike considers heavily restricting the behavior of the embedded lua interpreter until only an easily parse-able (maybe even pure / functional?) subset remains 4. The community uses an upgrade script to (seamlessly!) upgrade their codebases to the (declarative subset of) lua. 5. Someday the entire community ~still has a clean upgrade path to whatever the next great specification language will be, instead of having to rewrite their build specification from scratch (or more likely, never upgrading at all). CMake will continue spread like wildfire, and vast swaths of the open source community will lock themselves (and us via network effects) into messy imperative build specifications that will be impossible to upgrade (with the notable exception of the linux kernel), but the tup community can still take another path! -- -- tup-users mailing list email: [email protected] unsubscribe: [email protected] options: http://groups.google.com/group/tup-users?hl=en --- You received this message because you are subscribed to the Google Groups "tup-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
