> "Hari" == Raja R Harinath <[EMAIL PROTECTED]> writes:
Tom> For explicit rules (not suffix rules), there are some macros like
Tom> $< that we can't use.
Hari> But, we're talking about suffix rules like
Hari> [ ... ]
Hari> $(LTCOMPILE) -c -o $@ `test -f $< || echo '$(srcdir)/'`$<
I
Hi,
Tom Tromey <[EMAIL PROTECTED]> writes:
>> "Hari" == Raja R Harinath <[EMAIL PROTECTED]> writes:
>
> Hari> That code is there support non-srcdir builds in the face of
> Hari> 'make's with broken VPATH implementations. If you look at the
> Hari> Makefile, you'll see that it is checking to
> "Patrick" == Patrick Guio <[EMAIL PROTECTED]> writes:
Patrick> Which variableshall I use in each Makefile.am?
Patrick> nobase_include_HEADERS ? include_HEADERS ? or something
Patrick> else?
There are two basic ways to approach this.
One way is to put everything in the top-level Makefile.
Am Die, 2002-01-22 um 18.34 schrieb Tom Tromey:
> > "Ralf" == Ralf Corsepius <[EMAIL PROTECTED]> writes:
>
> Ralf> automake -a -f -c
> Ralf> [Don't use symlinks at all]
>
> Maybe, going forward, we should just always copy these files?
Hmm, why not?
> I.e., never symlink? Thoughts?
Let me r
Dear all,
I have a hierarchy of directories from the $(top_srcdir) like
$(top_srcdir)/includes1, $(top_srcdir)/includes1/sub1,
$(top_srcdir)/includes1/sub2, $(top_srcdir)/includes2 which contains c++
includes which I want to install in $(includedir) like
$(includedir)/includes1, $(includedir)/inc
>>> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes:
[...]
Tom> Even finding a way to reject non-srcdir builds for non-GNU make won't
Tom> help here.
At least it would help to clean up the _implicit_ rules,
wouldn't it?
Some people seems to not like this at all. The following
excerpt comes
> "Ralf" == Ralf Corsepius <[EMAIL PROTECTED]> writes:
Ralf> automake -a -f -c
Ralf> [Don't use symlinks at all]
Maybe, going forward, we should just always copy these files?
I.e., never symlink? Thoughts?
Tom
> "Hari" == Raja R Harinath <[EMAIL PROTECTED]> writes:
Hari> That code is there support non-srcdir builds in the face of
Hari> 'make's with broken VPATH implementations. If you look at the
Hari> Makefile, you'll see that it is checking to see whether 'make'
Hari> said that the source file w
> "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes:
Pavel> ChangeLog:
Pavel> * tests/asm.test: Use CCAS and CCASFLAGS instead of AS and
Pavel> ASFLAGS.
Thanks, I've checked this in.
Tom
Hello!
asm.test fails in the CVS version of Automake.
$ make check TESTS=asm.test VERBOSE=1
make check-TESTS
make[1]: Entering directory `/usr/local/src/automake/tests'
=== Running test ./asm.test
1
automake: Makefile.am: Assembler source seen but `CCAS' not defined in `configure.in'
2
automake
> That code is there support non-srcdir builds in the face of 'make's
> with broken VPATH implementations.
Ah, okay. Having never worked with such a 'make' this caught me off guard.
Thanks!
Phil
Phil Edwards <[EMAIL PROTECTED]> writes:
> Been playing with 1.5 and have been pretty pleased with the support for
> source files in subdirectories. I have noticed however something which
> strikes me as odd:
>
>% make
>make all-am
>make[1]: Entering directory `/tmp/pme/foo'
>so
Title: A product, and in this case products that are worth $1000 or more! I have taken the idea of a scam chainletter, and turned it into a MARKETING TOOL.! Now it is not a scam!!!
Please just play by the rules, this doesn't cost anything but your time and if everyone plays fair ever
Been playing with 1.5 and have been pretty pleased with the support for
source files in subdirectories. I have noticed however something which
strikes me as odd:
% make
make all-am
make[1]: Entering directory `/tmp/pme/foo'
source='/home/pme/easysems/main.cc' object='main.o' libtoo
Am Die, 2002-01-22 um 09.43 schrieb Jens Petersen:
> Tom Tromey <[EMAIL PROTECTED]> writes:
>
> > > "juhp" == Jens Petersen <[EMAIL PROTECTED]> writes:
> >
> > juhp> While the recent versioning of automake is a good thing, I
> > juhp> guess it introduces some issues with backward compatibili
Am Die, 2002-01-22 um 04.56 schrieb Tom Tromey:
> > "juhp" == Jens Petersen <[EMAIL PROTECTED]> writes:
>
> juhp> While the recent versioning of automake is a good thing, I
> juhp> guess it introduces some issues with backward compatibility.
> juhp> For example quite a few packages/people ass
Tom Tromey <[EMAIL PROTECTED]> writes:
> > "juhp" == Jens Petersen <[EMAIL PROTECTED]> writes:
>
> juhp> While the recent versioning of automake is a good thing, I
> juhp> guess it introduces some issues with backward compatibility.
> juhp> For example quite a few packages/people assume that
17 matches
Mail list logo
