I have been so overwhelmed that all my side efforts have been tiny things for a year - actually since last Christmas when I had a few days off in a row and my wife wasn't demanding other work.
JSON Serialisation of GNU Makefiles:
I got quite far then and now, one year later, I'm hoping I will have the time to finish off the difficult bits: it's a way to get GNU Make to print out its internal database of targets and rules as JSON.
You get output with all the targets, all the options on those targets. Basically everything that make knows. I have most of it working but not directory targets for example. Why do this? Well there are many uses:
1. tools to rewrite makefiles - to simplify them or find duplication and implement transforms that remove it. e.g. all your CC commmands have nearly the same parameters - so make a variable or a macro containing the common ones and simplify all your commands (basic things like that could still be very handy).
2. tools that translate makefiles into other build formats. This is a big one for me. Make is like an almanac of all the build features one can have (nearly) but all done in various ways that make them of limited use. There are existing tools that are better in some areas and always the holy grail of the one build system that does it all and does it right. One is never going to get there however if one cannot convert existing work with a fair degree of ease and in a way that can be shown to truly do what is expected.
Sorry if I think the existing examples are not very good and that upsets you - they're all tailored for specific situations and work really well in those situations and if that's all you need then they tend to seem amazing. ...but...when you try to do something that's not in the examples they can be very inflexible. tup's basic idea (inverted dependency tree) is what I want because it lets you have giant makefiles that load quickly. The ability to describe a logical structure like Meson does is important too. Cross platform tests and option setting like CMake...check. Then some features from SBS (Symbian build system which none of you will know) and all the really interesting features of GMake that suck in implementation/performance such as pattern rules.
So this Christmas I hope to update to the latest version of gmake and handle directories.
JSON Serialisation of GNU Makefiles:
I got quite far then and now, one year later, I'm hoping I will have the time to finish off the difficult bits: it's a way to get GNU Make to print out its internal database of targets and rules as JSON.
https://github.com/tnmurphy/gmake-experimental (feature/jprint branch)
It's a companion to the print-database option:
You get output with all the targets, all the options on those targets. Basically everything that make knows. I have most of it working but not directory targets for example. Why do this? Well there are many uses:1. tools to rewrite makefiles - to simplify them or find duplication and implement transforms that remove it. e.g. all your CC commmands have nearly the same parameters - so make a variable or a macro containing the common ones and simplify all your commands (basic things like that could still be very handy).
2. tools that translate makefiles into other build formats. This is a big one for me. Make is like an almanac of all the build features one can have (nearly) but all done in various ways that make them of limited use. There are existing tools that are better in some areas and always the holy grail of the one build system that does it all and does it right. One is never going to get there however if one cannot convert existing work with a fair degree of ease and in a way that can be shown to truly do what is expected.
Sorry if I think the existing examples are not very good and that upsets you - they're all tailored for specific situations and work really well in those situations and if that's all you need then they tend to seem amazing. ...but...when you try to do something that's not in the examples they can be very inflexible. tup's basic idea (inverted dependency tree) is what I want because it lets you have giant makefiles that load quickly. The ability to describe a logical structure like Meson does is important too. Cross platform tests and option setting like CMake...check. Then some features from SBS (Symbian build system which none of you will know) and all the really interesting features of GMake that suck in implementation/performance such as pattern rules.
So this Christmas I hope to update to the latest version of gmake and handle directories.