Tom Tromey wrote:
"Emile" == Emiliano [EMAIL PROTECTED] writes:
Emile I'm trying to create an automake file that has rules to
Emile uppercase files. For example I have something.ext and I want
Emile it to create a copy SOMETHING.EXT. I tried with this:
Emile pkgdata_DATA =
On Jan 31, 2001, Emiliano [EMAIL PROTECTED] wrote:
Tom Tromey wrote:
Write explicit rules.
SOMETHING.EXT: something.ext
Yes, but I'd rather not if it can be avoided.
I'm afraid it can't. Unix is case-sensitive, why shouldn't `make' be?
Well... I suppose you could do something about it
Alexandre Oliva wrote:
On Jan 31, 2001, Emiliano [EMAIL PROTECTED] wrote:
Tom Tromey wrote:
Write explicit rules.
SOMETHING.EXT: something.ext
Yes, but I'd rather not if it can be avoided.
I'm afraid it can't. Unix is case-sensitive, why shouldn't `make' be?
But that's the
This patch makes it possible to have AC_SUBST keywords in for instance
library names, allowing for much greater flexibility. It depends on
patch 1/2, of course.
2001-02-01 Lars J. Aas [EMAIL PROTECTED]
* automake.in ($quote_ats): New.
($MACRO_PATTERN, $CANONICALS): Allow '@'s
"Tom" == Tom Tromey [EMAIL PROTECTED] writes:
"Akim" == Akim Demaille [EMAIL PROTECTED] writes:
Akim It means that for instance we could have
Akim a b c: d e f
Akim in a .am file, and have file_contents_with_transform (provided
Akim we taught it that a, b and c are special targets) push @a,
"Tom" == Tom Tromey [EMAIL PROTECTED] writes:
Tom The reason is only historical. Feel free to change it.
I'm applying this. Sure, more clarification is needed in this area.
I find it especially hard to track failures of substitution since
Automake uses @FOO@ just like AC_SUBST :( Can't we
"Tom" == Tom Tromey [EMAIL PROTECTED] writes:
Tom Later we see:
Tom # Generate rule for `.o'. . 's/^\@EXT\@\.o:/' . $obj
Tom . '.o: ' . $source . '/g;'
Tom I think we need to quote $obj and $source here; this was handled
Tom in the old code.
I did not change anything in the
"Akim" == Akim Demaille [EMAIL PROTECTED] writes:
Akim First I want to write/enhance a test that fails on this.
Sorry for being that dumb. I finally understood the problem. Here is
what I'm applying:
Index: ChangeLog
from Akim Demaille [EMAIL PROTECTED]
* automake.in
"Akim" == Akim Demaille [EMAIL PROTECTED] writes:
Akim * automake.in (file_contents): Rewrite: instead of trying to parse
Akim it line by line, first swallow it completely into $CONTENTS,
Akim *then*, parse it *paragraph* by paragraph.
I see this went in.
What is the rationale for this
"Akim" == Akim Demaille [EMAIL PROTECTED] writes:
Akim * automake.in (%factored_dependencies): New.
Akim (file_contents): Use it.
Akim (handle_phony): Rename as...
Akim (handle_factored_dependencies): this.
Akim * subdirs.am: No need for convolved syntax to declare .PHONY.
Akim +#
"Akim" == Akim Demaille [EMAIL PROTECTED] writes:
Akim My `plan' is what I implemented in the patch named
Akim factored-dependencies.
Thanks. I missed some patches in my inbox last night.
BTW subdirs.am doesn't have .PHONY entries for the *clean-recursive
rules. Is this intentional?
Tom
"Akim" == Akim Demaille [EMAIL PROTECTED] writes:
Akim First I want to write/enhance a test that fails on this.
Try `make TESTS=subobj4.test VERBOSE=t check'.
That will tell you all about the problem.
Tom
On Wed, Jan 31, 2001 at 05:02:06PM +0100, Lars J. Aas wrote:
: I've revised the patch to include the latest changes from CVS Autoconf,
: which made the complate patch somewhat simpler than before. I even corrected
complete
My fingers are slippy today.
Anyways, are the people
On Wed, Jan 31, 2001 at 11:22:15AM -0700, Tom Tromey wrote:
"Akim" == Akim Demaille [EMAIL PROTECTED] writes:
Akim * automake.in (%factored_dependencies): New.
Akim (file_contents): Use it.
Akim (handle_phony): Rename as...
Akim
On Wed, Jan 31, 2001 at 11:19:37AM -0700, Tom Tromey wrote:
"Akim" == Akim Demaille [EMAIL PROTECTED] writes:
Akim * automake.in (file_contents): Rewrite: instead of trying to parse
Akim it line by line, first swallow it completely into $CONTENTS,
Akim *then*, parse
On Wed, Jan 31, 2001 at 11:27:05AM -0700, Tom Tromey wrote:
"Akim" == Akim Demaille [EMAIL PROTECTED] writes:
Akim My `plan' is what I implemented in the patch named
Akim factored-dependencies.
Thanks. I missed some patches in my inbox last night.
BTW subdirs.am doesn't have .PHONY
stamp-h? files in subdirs are still being created in the wrong locations
by an automake configure script. The problem was in AM_CONFIG_HEADERS.
I fixed it, but is dependent on the autoconf beta. Patch attached.
I was thinking of attempting to eliminate the need for the recreation of
stamp-h?
(_AM_DIRNAME): helper function which basically implements an sh
`dirname` in m4
Only have 1 problem with it: no support for DOS-style paths (and this is
conveniently not tested in your dirname.test either :-P).
It's bad enough working on patches for proper DOS/Win support when
The amtraces functionality for AC_CONFIG_FILES is totally broken.
Anyone mind if I spend a few minutes on it?
Derek
--
Derek Price CVS Solutions Architect ( http://CVSHome.org )
mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com )
--
I don't suffer from stress.
This patch gets rid of @phony, using only %dependencies. depend
makes it somewhat more digest. It also fixes the problem Tom spotted,
where my version of @phony was improperly initialized globally.
There are other targets that can take advantage of this: clean etc.,
in fact, those which are
Actually, it seems to me there is not enough paragraph rules at all in
automake. Instead of the attrocious
@SUBDIRS@ for subdir in $(@DIST_SUBDIR_NAME@); do \
@SUBDIRS@ if test "$$subdir" = .; then :; else \
@SUBDIRS@ test -d $(distdir)/$$subdir \
@SUBDIRS@ ||
"Derek" == Derek R Price [EMAIL PROTECTED] writes:
Derek by an automake configure script. The problem was in
Derek AM_CONFIG_HEADERS. I fixed it, but is dependent on the
Derek autoconf beta.
The next automake must be compatible with the old autoconf. So this
patch can't go in as-is.
Tom
Tim Van Holder wrote:
(_AM_DIRNAME): helper function which basically implements an sh
`dirname` in m4
Only have 1 problem with it: no support for DOS-style paths (and this is
conveniently not tested in your dirname.test either :-P).
Yeah, sorry. I noticed that, but I
23 matches
Mail list logo
