On Wed, 2014-02-19 at 22:34 -0700, Lester Scofield wrote: > I am thinking about writing a module for SQLite. My first goal is to > create a $(sqlite) function. I'd like it to behave similar to the > sqlite3 shell, with its added .commands and such. I think there are > some things I'd like access to that I can't get with gmk_eval. Here > are some thoughts I had:
There's very little in the way of description on WHY many of these things are needed, so I can't really say how appropriate my suggestions below might be. > 1) it would be nice to load the module from the make command line, so > that the module can affect settings before Makefiles are read. You can do this, actually, through the magic of the --eval option. > 2) Modify makefile name search (e.g. I'd like to add GNUmakeDB to the > list) Well, you can also do this via --eval 'include GNUmakeDB', or set MAKEFILES, or use the -I option, or send 'include GNUmakeDB' via gmk_eval(). > 3) add a handler for GNUmakeDB that does some sort of select that > generates the "makefile". I don't really understand this. > 4) affect the command line options (I like to set things like -d -p -r > -R -n --trace, etc) You can simply set MAKEFLAGS at any time, in a makefile, via gmk_eval, or whatever. > 5) affect the built-in rules and variables (can use eval, but a direct > access may be nice) Well, I'd need to understand what you want. It's not so simple to do that; once all the makefiles are completely read in make goes through a sanitization/normalization process on all the rules. Once that is accomplished, it's very tricky to go back and further modify rules (this is why it's illegal for an $(eval ...) in a recipe to create a new target). > 6) set the modify timestamp, has been updated flag, or --assume-old > timestamp for targets I understand the desire for this, but again just allowing access to it at any time is potentially dangerous. > 7) add support for non-filesystem targets/dependencies: I'd like to > generate a prerequisite DAG yet retain the ability to set their modify > timestamps, so .PHONY would not work. This would basically be like > the existing AR(member) support. I don't think I understand what you're looking for here. > 8) fix the whitespace in target name issue. This seems pretty orthogonal to me... how does it relate to load features? _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
