Re: load features

[Paul Smith]

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?