[Top][All Lists]

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

Re: Feature request

From: Ralf Wildenhues
Subject: Re: Feature request
Date: Tue, 23 Sep 2008 23:08:20 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

Hi Akim,

* Akim Demaille wrote on Tue, Sep 23, 2008 at 04:35:50PM CEST:
> I'm slowly getting rid of my recursive Makefiles.  Instead I have one  
> per directory, and a few Makefile.ams that include them.  Of  
> course I have to prefix all my file names with the name of the  
> directory, and I find that this explicit name is actually clutter.  I  
> don't think automake can be educated to guess by itself where to prepend 
> the directory name,

I agree that that would be too much magic, and probably too fragile.

> yet it would be quite easier to have some variable 
> that would expand to the prefix of the included file.

Sounds like a reasonable wish.  Let's look at an example.
Probably you want a set of these:

- one for the full relative path to the  (%AMSUB%=foo/bar)
  (this one would be '.' if in the same directory)
- likewise, including final slash (%AMPREFIX%=foo/bar/)
  (needed if the prefix can also be empty, to avoid './')
- likewise, but flattened (%AMFLAT%=foo_bar_)
- reverse of the full relative path (%AMREV%=../..)
- maybe a set of these for only the path to the next included snippet?
- would that be enough for all use cases?


  --- ---
  include foo/

  --- foo/ ---
  # Yes, it is very ugly and IMNSHO an automake misfeature that
  # the next line requires an %AMPREFIX%.  Unfortunately, fixing
  # it would break user's scripts.
  include %AMPREFIX%bar/

  --- foo/bar/ ---
  FOO_FLAGS = -I%AMREV%/include

Yuck.  That's already quite ugly, nothing I'd want to edit regularly.
We could use even shorter abbreviations.  Suggestions?

And yes, if the resulting snippets are to be usable also from the same
directory, then most usages need AMPREFIX and not AMSUB, if non-GNU make
should work well, too.  This is probably not easy on users.

> Thanks for the good work!

Thanks for the feedback, and the suggestion.

> [1] whatever the name, but not too long.  Maybe a symbol, $/ for  
> instance.

I'd really hate to invade make's namespace.  They may come up with this
really cool new makefile variable, and we can't use it then.  :-/


reply via email to

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