[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Include directive for all generated

From: Steffen Dettmer
Subject: Re: Include directive for all generated
Date: Thu, 15 Apr 2010 17:51:12 +0200

On Thu, Apr 15, 2010 at 8:02 AM, Ralf Wildenhues <address@hidden> wrote:
> * Steffen Dettmer wrote on Wed, Apr 14, 2010 at 11:53:56AM CEST:
> > [on this idention level]
> Well, can you give a specific example?  I can probably see that
> this might be useful, but having a convincing example always
> helps.  Really, designing new interfaces should be done right.

Yes, of course you are right and ideas may help, I just hope you
don't waste to much time in case I write about ideas that are
simply too far off and wrong :)

> We could easily have a fairly fat interface
>  AM_MAKEFILE_INCLUDE([fragment], [placement], [pattern], [id])
> where fragment names the file to include, placement is 'top' or
> 'bottom' or so, pattern matches the files to
> affect, and id a string or number which could mean that a later
> fragment with the same id will replace the earlier one.

(hum... I'm not sure what this would allow to do... anyway.)

> I am just not seeing how it can be useful.  All the decisions
> of which fragments to include where _still_ have to be done at
> the time automake is run, the only variation postponed to
> configure run time you get is conditionals and @substitution@
> expansions (as usual) within the files.

(I try to give some examples, but probably they are bad ones)

The etags program on many of our build hosts have a bug (fixed in
meantime) leading to an invalid tags file when hitting some
special input (some struct syntax). Makefile uses some awk
construction to generate the list of files. As workaround someone
propose to add some if in the awk script to simply skip the
related file. But AFAIK there is no way to run some `find and
replace' on rules from

Compiler and linker of one toolchain may leave zero-length files
in case or error / interruption (on next make leading to errors).
As workaround someone could imagine to `customize' the
$(mylib_a_AR) rule by appending some "|| rm -f $@".

Don't know if appropriate here (probably not) but someone may
wish to have a specific error code for a place of failure, let's
say "$(mkinstalldirs) ... || exit 45" to get exactly this error
code in case this mkdir fails.

Once there was a bug that if OBJEXT = .obj, sources from subdirs
won't compile (i.e. `xyz_SOURCES = a.c subdir/b.c' lead to a.obj
but no b.obj).

There are compilers not supporting `-o object.o' leading to
trouble when using xyz_CFLAGS - but this is better to be solved
by making wrapper scripts that add support for -o.

The dist rule (for at least older automake) has `$(AMTAR) chof'
which fails for long file names. We wanted to remove the `o'. We
had to write a wrapper script `lazytar' which internally drops
the 'o' option.

For some reason on cygwin ...gzip -c >... wasn't working because
for some reason regardless all binary mount options and
environment variables CRLF conversion took place on piping
resulting in broken zip files. We wanted to try to replace
$(AMTAR) chof - $(distdir) | GZIP=$(GZIP_ENV) gzip -c >$(distdir).tar.gz
$(AMTAR) chof - $(distdir) > $(distdir).tar \
  && GZIP=$(GZIP_ENV) gzip -c $(distdir).tar

> > Probably all this are examples of DONT-DOs because relying on
> > internals that change without prior notice.
> We are purely speaking about new, to-be-public, user interfaces
> here.  Things that users should be able to use with Automake
> 1.12.  None of the above applies to current Automake.

Yes, right, but I meant that the `customizations' would be DONTs
for example because accessing variables / identifiers that are
not considered to be part of the documented API (such as
$(distdir) or relying on the structure of some mkinstalldirs

(also, for autoconf it turned out that many of the
`customizations' we did, proabaly better had been done
differently; probably the same of the examples above)

> > But I think this is out of scope here. Much too complicated
> > and it would be more customizing automake than using a
> > feature of it.
> Well, it is true that Automake is less easily extensible than it could
> be. The above could be a step in the right direction.

Yes, sure, but there are risks as well, you know, for example
`For each useless function there will be one who calls it'
(making future API cleanups harder) and `if the API has a clean
way a thing is supposed to be done but also have flexible hooks
archiving the same, half the people will only use the hooks' and
the experience that over-designed APIs can harm when finding that
the later needed case isn't supported althrough so many unneeded
cases are and finding it harder to fix the over-desigend API
instead of extending a minimalistic one. Not having good examples
showing the need for an API extension could be an indicator for that :)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]