This way, under a VPATH build, this first target would ensure compilation of the
specified paths in their matching locations (i.e.
$(top_srcdir)/src/base/paramx.f90 would lead to
$(top_builddir)/src/base/paramx.lo), and the rest of the libraries could then be
compiled normally.
Adding "subd
On 11/02/2016 08:06 PM, Raphaël Halimi wrote:
Hi Peter,
Thanks for your answer.
Just to make sure I understand:
CLEANFILES += data/.dirstamp
data/.dirstamp:
@$(MKDIR_P) data
@: > $@
This creates a directory "data", and then a file ".dirstamp" in this
directory by redirecting t
Hi Peter,
Thanks for your answer.
Just to make sure I understand:
> CLEANFILES += data/.dirstamp
>
> data/.dirstamp:
> @$(MKDIR_P) data
> @: > $@
This creates a directory "data", and then a file ".dirstamp" in this
directory by redirecting the (empty) result of the "true" command to
Hi Raphael,
I have the following in my Makefile.am
CLEANFILES += data/.dirstamp
data/.dirstamp:
@$(MKDIR_P) data
@: > $@
data/foo.txt: data/.dirstamp
Cheers,
Peter
On 10/28/2016 05:46 AM, Raphaël Halimi wrote:
Hi,
I have a problem with parallel build trees (a.k.a. VP
Le 27/10/2016 à 23:06, Russ Allbery a écrit :
> Raphaël Halimi writes:
>
>> According to section 2.2.6 of GNU automake documentation:
>
>> "The build tree usually has the same subdirectory layout as the source
>> tree; its subdirectories are created automatically by the build system."
>
>> Unfo
Raphaël Halimi writes:
> According to section 2.2.6 of GNU automake documentation:
> "The build tree usually has the same subdirectory layout as the source
> tree; its subdirectories are created automatically by the build system."
> Unfortunately, it doesn't seem to be true for the SCRIPTS prim
Hi,
I have a problem with parallel build trees (a.k.a. VPATH Builds).
I'm trying to use GNU autotools to distribute a shell script that need
to be installed with some other files (sample configuration, man pages,
data, etc etc).
Nothing in this project needs to be compiled, but the scri
On 06/11/2014 04:18 PM, Rhys Ulerich wrote:
> Other than resorting to the shell in a target, is there a way to cause
> Automake to produce a symlink from the source tree into the build tree
> if-and-only-if the build is VPATH?
Yes, for new enough autotools. See how gnulib does it for GN
Other than resorting to the shell in a target, is there a way to cause
Automake to produce a symlink from the source tree into the build tree
if-and-only-if the build is VPATH?
I've some non-generated Python code (srcdir) relying on generated
Python code (builddir) and I'd like to be ab
List the .c and .h files in FOO_SOURCES.
H
obar/george.c and if that works, either put sources next to
>> this Makefile.am or move the guts of it to
>> pathprob/foobar/blah/Makefile.am
>
> Yes, removing the vpath and moving george.c up one level works around
> the problem
> in the test case.
> Should I file a bug
fails. It seems that
> make dist is unable to follow vpath. Is this a known problem?
>
> To reproduce the problem, do
> wget http://kegel.com/pathprob.tgz
> tar -xzvf pathprob.tgz
> cd pathprob
> touch NEWS README AUTHORS ChangeLog
> aclocal
> autoconf
>
On Mon, Oct 22, 2012 at 3:12 PM, Paul Davis wrote:
>> It doesn't quite solve the problem in my real world situation;
>> "make dist" didn't copy #included files, and I needed to add something like
>> EXTRA_DIST = foobar
>> to pathprob/Makefile.am.
>
> This is to be expected, you have to tell autoto
e.am or move the guts of it to
> pathprob/foobar/blah/Makefile.am
Yes, removing the vpath and moving george.c up one level works around
the problem
in the test case.
Should I file a bug for the fact that vpath and dist don't work together,
or is that already documented somewhere?
It do
I don't understand automake's "make dist" support, and could use a clue.
I've boiled my problem down to the following tiny test case, in which
"./configure; make" works, but "make dist" fails. It seems that
make dist is unable to follow vpath. Is th
r.am:
+## Creative quoring to avoid spurious matches in the grepping
+## of Makefile.in, later.
+ echo '#' 'foobar' 'was 'here' '#' > $@
+END
+
+$ACLOCAL
+$AUTOCONF
+$AUTOMAKE
+
+./configure
+
+# OK, so the developer wants to interactively try out ho
ground solution for the moment: extend
> the distcheck target to honor a switch (which should probably be an
> environment variable, say 'DISTCHECK_USE_VPATH') telling to perform
> simply an in-tree build (while continuing to perform VPATH builds by
> default).
Well, if we ch
On Sun, 16 Jan 2011, Ralf Wildenhues wrote:
I reject the notion of disallowing VPATH builds with GNU make only.
The reason is simple: I make good use of this feature every time I test
the Automake package with some non-GNU make (I build several platforms
off of one tree shared via NFS). It
an
environment variable, say 'DISTCHECK_USE_VPATH') telling to perform
simply an in-tree build (while continuing to perform VPATH builds by
default).
This new behaviour would be completely backward-compatible, more
flexible, and wouldn't overly penalize non-GNU makes.
Then we co
from this hunting for regressions in
Automake proper harder than it should be, because there are many
failures which could be testsuite regressions, or regressions for
features we don't advertise, or long-standing issues for which it thus
is not imperative that we fix them quickly.
I reject the not
hese failures apparently have
> two reasons:
>
> 1) Cleanup failed to remove some directory because of stale NFS handles,
>
> 2) The native make is not up to the task of VPATH builds.
>
> Now, distcheck is not a GCS-mandated target, so it need not work
> everywhere. Als
> -Original Message-
> From: Ralf Wildenhues [mailto:ralf.wildenh...@gmx.de]
> Sent: Monday, November 29, 2010 2:33 PM
> To: Daily, Jeff A
> Cc: automake@gnu.org
> Subject: Re: make distclean fails for conditional nested package with VPATH
> build
>
> Hello
Hello Jeff,
* Daily, Jeff A wrote on Mon, Nov 29, 2010 at 11:04:04PM CET:
> I had a user point out that "make distclean" from within their VPATH
> build failed due to a missing, optional nested package. The nested
> package is called "tascel". I have in configure.a
I had a user point out that "make distclean" from within their VPATH build
failed due to a missing, optional nested package. The nested package is called
"tascel". I have in configure.ac:
AC_ARG_ENABLE([tascel], [omit for brevity], [], [enable_tascel=no])
AM_CONDITIONAL([E
;> some datafiles that are required for tests are in the correct place
>>>>> (my tests don't need to be installed with "make install"). However,
>>>>> when I use VPATH builds with "../configure", I don't know how to get
>>>>&
e
>>>> (my tests don't need to be installed with "make install"). However,
>>>> when I use VPATH builds with "../configure", I don't know how to get
>>>> my data files copied from the source to the current build path.
> cpre
rect place
(my tests don't need to be installed with "make install"). However,
when I use VPATH builds with "../configure", I don't know how to get
my data files copied from the source to the current build path.
I've just read up on VPATH, and I think gmake is
ests don't need to be installed with "make install"). However,
> > when I use VPATH builds with "../configure", I don't know how to get
> > my data files copied from the source to the current build path.
> >
> > I've just read up on
On Oct 30, 2010, at 5:17 PM, Jason Curl wrote:
> Hello,
>
> When building my package with "./configure" everything works well as some
> datafiles that are required for tests are in the correct place (my tests
> don't need to be installed with "make i
Hello,
When building my package with "./configure" everything works well as
some datafiles that are required for tests are in the correct place (my
tests don't need to be installed with "make install"). However, when I
use VPATH builds with "../configure&quo
* Steffen Dettmer wrote on Fri, Feb 12, 2010 at 02:15:04PM CET:
> Just because of my curiosity, when writing portable packages
> (i.e. packages compiling ON many platforms), on which platform
> this is recommended to do so?
I'd recommend testing on as many as you can get hold on, and as
old and ne
Steffen Dettmer wrote:
Just because of my curiosity, when writing portable packages
(i.e. packages compiling ON many platforms), on which platform
this is recommended to do so? GNU/Linux is great for working
because it has all the efficient tools, but bad for testing,
because it is too powerful
Hi Ralf,
thanks again for your helpful message. It is interesting how many
mistakes (non-portable constructions) can be in such a small
snipped I wrote. Thanks for spotting.
On Wed, Feb 10, 2010 at 9:29 PM, Ralf Wildenhues wrote:
> * Steffen Dettmer wrote on Wed, Feb 10, 2010 at 11:01:34AM CET:
>
Hello,
* Steffen Dettmer wrote on Wed, Feb 10, 2010 at 11:01:34AM CET:
> module=xyz
> _mak=${module}.mak
> echo "# Autogenerated by $0" > ${_mak}
> echo "${module}files = \\" >> ${_mak}
> find directoty1 directory2 directory3 -type f \
>-not -path '*/CVS*' \
With find, -not is not po
On Tue, Feb 9, 2010 at 7:00 PM, Sylvestre Ledru
wrote:
> Hmm, I have more than 7000 data files and their names are relevant :/
> (Like in java with the name of the object which matches the filename)
>
> It is going to be tricky to handle on such number of files ...
To manage them, you now probabl
Hi Sylvestre,
* Sylvestre Ledru wrote on Tue, Feb 09, 2010 at 07:00:51PM CET:
> Le samedi 06 février 2010 à 18:56 +0100, Ralf Wildenhues a écrit :
> >
> > data-in-build-tree: data-in-source-tree
> > cp $(srcdir)/data-in-source-tree data-in-build-tree
> Hmm, I have more than 7000 data fil
> Both, I need them at building time: myscript calls the binaries to
> > transform the myData.sci to myData.bin.
> > And they are both needed for my application at runtime.
>
> Can you let your script use $srcdir/myData.sci instead of myData.sci?
I wish but I can't, I need them
file /must/ be in current dir (builddir) for proprietary tool:
> __heap.o: lib/__dfl_heap.o
> cp -f $< $@
>
> Make finds $(srcdir)/lib/__dfl_heap.o via VPATH, if any, and
> sets `$<' accordingly
Using $< is portable only inside inference rules (.suf1.suf2 rule
cp -f $< $@
Make finds $(srcdir)/lib/__dfl_heap.o via VPATH, if any, and
sets `$<' accordingly
(of course this won't work if in the above example the
filenames (including path parts, if any) of data-in-source-tree
and data-in-build-tree and exactly the same).
I case this is portab
at runtime.
Can you let your script use $srcdir/myData.sci instead of myData.sci?
Typically, there are two ways to get out of the VPATH problem: either
prefix all paths in your tools with the right ones, (this can usually be
done more elegantly if the tool has some -I flag to amend its search
path, like
> > $(top_builddir)/bin/myscript $(top_builddir)/dataDir/myData.sci
> >
> > Obviously, this works when I am building my application in the source
> > tree but it fails when building as VPATH.
> >
>
> It is not clear what you wanna accomplish and why it doesn'
building as VPATH.
It is not clear what you wanna accomplish and why it doesn't work as you
desire.
I cannot change top_builddir by top_srcdir since I need both the data
and script to be available in the build tree.
Are myscript and myData.sci distributed or built? Why do you need the
Hello,
I am trying to enable the VPATH path build of a software.
The whole compilation process is fine but I am stuck at the end of the
process.
I need to call a script to finish the build process. This script will be
run against data files.
In my Makefile.am, I have:
all-local: macros
macros
* Peter Johansson wrote on Mon, Jun 08, 2009 at 06:52:18PM CEST:
> Ralf Wildenhues wrote:
>> Oh. It seems your first message in this thread didn't make it to the
>> list then. Dunno whether it was eaten by the spam filter, but it is
>> not sitting in the moderation queue. You might consider rese
Hi Peter,
* Peter Johansson wrote on Fri, Jun 05, 2009 at 07:50:56PM CEST:
> Ralf Wildenhues wrote:
>> could you please post this on-list unless it has huge size; that way,
>> others can profit (or comment, critize, help, ...), too.
>>
> Sorry, I don't understand. I attached the tarball and CC:
Hi Ralf,
Ralf Wildenhues wrote:
could you please post this on-list unless it has huge size; that way,
others can profit (or comment, critize, help, ...), too.
Sorry, I don't understand. I attached the tarball and CC:d the automake
list. Are attachments filtered away when automake list is in
Hello Peter,
> On Jun 5, 2009 8:42am, Peter Johansson wrote:
>
>> I've attached a modified version of your package for which `make
>> distcheck' works. I'm not sure what structure you desire for the
>> installed header files, but that should be easy to adjust.
could you please post this on-l
johnwohlb...@gmail.com wrote:
Thanks very much for the help Peter. The goal is to have the headers
installed and preserve the directory structure of the src. ie, after
make install
@prefix@/include/comp1/
comp1.hh
processed.hh
@prefix@/include/comp2/
comp2.hh
I haven't yet looked at your modif
On Jun 5, 2009 8:42am, Peter Johansson wrote:
Hi John,
John Wohlbier wrote:
Attached is an example package. What I left out of my original email was
that I'm putting the Makefile.am's out of the src/ directory to enable
building other architecture specific binaries within the same build.
Hope
Thanks again for the help Ralf.
>
> If that still doesn't help, it is useful to post a small example
>
> package.
>
Attached is an example package. What I left out of my original email was
that I'm putting the Makefile.am's out of the src/ directory to enable
building other architecture specific
Just because I think my reply is easily misunderstood:
* Ralf Wildenhues wrote on Thu, Jun 04, 2009 at 07:47:50AM CEST:
> * johnwohlb...@gmail.com wrote on Thu, Jun 04, 2009 at 12:24:29AM CEST:
> >
> > from lib1/Makefile.am
> >
> > nobase_include_HEADERS = \
> > $(header_file_list)
>
> The above
Hello John,
* johnwohlb...@gmail.com wrote on Thu, Jun 04, 2009 at 12:24:29AM CEST:
> I'm having troubles with out of tree (vpath) builds, using
> nobase_include_HEADERS, and *.in files processed by configure.
I think you're making things more complicated than they need to
I'm having troubles with out of tree (vpath) builds, using
nobase_include_HEADERS, and *.in files processed by configure.
I have a collection of components in a component library.
src/
src/lib1/
Makefile.am
header1.hh
types.hh.in
source1.cc
src/lib2/
Makefile.am
header2.hh
source2.cc
I
tooled project which I can successfully
>> configure/build using something like ../project/configure && make. Is
>> there some way to express a non-source dependency so that it gets
>> "picked up" in a VPATH build? Maybe symlinked?
>
> Yes, you can add pre
t gets
> "picked up" in a VPATH build? Maybe symlinked?
Yes, you can add prerequisites to the all-local target. You can write
rules for these prerequisites the same way you would write rules for
them in a Makefile.
> Specifically, I've got a log4cxx.properties file used by my &
Hi all,
I've got an autotooled project which I can successfully
configure/build using something like ../project/configure && make. Is
there some way to express a non-source dependency so that it gets
"picked up" in a VPATH build? Maybe symlinked?
Specifically, I'
When I do vpath build in automake_test/tmp/build, what I get is that beam
file is placed into tmp/build/src/ folder, not into tmp/build/ebin/.
What I like to see is to have ebin folder in vpath build directory and have
the automake_test.beam file in ebin, like so
tmp/build/ebin/automake_test.beam
Guillaume Rousse wrote:
> Also sprach Ralf Wildenhues:
>> This machinery is all present in automake.in (but not accessible from
>> outside). Sorry, I haven't worked on this more yet.
> Which basically there is no other solution without modyfing automake
> currently, right ?
>
> OK, I'll release c
Also sprach Ralf Wildenhues:
> This machinery is all present in automake.in (but not accessible from
> outside). Sorry, I haven't worked on this more yet.
Which basically there is no other solution without modyfing automake
currently, right ?
OK, I'll release camlimages in current state (after al
Hello Guillaume,
* Guillaume Rousse wrote on Wed, Jan 10, 2007 at 11:56:09AM CET:
>
> foo1.ml
> foo2.ml
> subdir/foo3.ml
> subdir/foo4.ml
> etc...
>
> My current option is to build object files in the same directory as the
> corresponding ource file (actually, it is ocaml compiler defaut
> behav
:
MYSOURCEFILES = foo1.ml foo2.ml subdir/foo3.ml subdir/foo4.ml
MYOBJECTFILES = $(MYSOURCEFILES:.ml=.cmo)
Howevever it breaks VPATH build for object files in subdirectories, as
it tries to output a file in a non-existing build subdirectory...
Is there a a way to pre-create all those subdirectories in my
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Stepan,
Maybe you remember this story about correctly searching for
the files to compile looking at VPATH. I am using it for
quite some time without problems.
Do you think that this change could be included in a future
version of Automake
Hi,
Stepan Kasal wrote:
> Hello,
>
>
> Suggested code for today: ;-)
>
> `IFS=:; v=$(VPATH); \
> for d in '' $$v; do \
> test -n "$$d" && d=$$d/; \
> test -f $${d}%SOURCE% && echo $$d
Hello,
On Fri, Oct 21, 2005 at 10:58:44PM +0200, Harald Dunkel wrote:
> Stepan Kasal wrote:
> > `IFS=:; x=':$(VPATH)'; \
> > for d in $$x; do \
> > test -n $$d && d=$$d/; \
> > test -f $${d}%SOURCE% && echo
Stepan Kasal wrote:
>
> Your proposal looks good, except I think it might be better to use single
> quotes around $(VPATH).
> And the quoting around $d, which I introduced, is redundant.
>
> That yields:
>
> `IFS=:; x=':$(VPATH)'; \
> for d in
security hole.
I've just checked POSIX: it seems that word splitting is not allowed there.
So my code was wrong, sorry.
> I have another concern: In your version $(srcdir) gets
> a higher priority than the $(VPATH) set in Makefile.am.
Yes, you are right: we should simply obey VPAT
Hi Stepan,
Stepan Kasal wrote:
>
> So I suppose something like this
>
> `IFS=:; for d in '' '$(srcdir)' $(VPATH); do \
> test -n "$$d" && d=$$d/; \
> test -f "$$d"%SOURCE% && echo "
Hello Harald,
I'm afraid I cannot judge your suggestion either; we'll have to wait
for Alexandre.
But _if_ it'll be accepted, I would like to point some glitches:
Your proposal, reformatted:
`test -f '%SOURCE%' || (VPATH=$(VPATH); test "$$VPATH" \
Hi folks,
Ralf Wildenhues wrote:
>
> What exactly does not work for you?
I tried to use
VPATH = $(srcdir):$(top_srcdir)/some/common/dir
in Makefile.am.
> In what circumstances?
I am not sure what you mean by "circumstances". I am trying to
build a C++ library
Hi Harald,
* Harald Dunkel wrote on Mon, Oct 17, 2005 at 06:02:09PM CEST:
>
> Would it be possible to rely upon $(VPATH) in depend2.am?
> Instead of
>
> `test -f '%SOURCE%' || echo '$(srcdir)/'`%SOURCE%
>
> something like this could work, to
Hi folks,
Would it be possible to rely upon $(VPATH) in depend2.am?
Instead of
`test -f '%SOURCE%' || echo '$(srcdir)/'`%SOURCE%
something like this could work, too (not verified yet):
`test -f '%SOURCE%' || (VPATH=$(VPATH); test "$$VPATH&q
obably happening here is that make is looking up the filename
and the underlying operating system sees that it does exist (because
it's case-insensitive).
But make does not understand this.
ad> - but Make no longer understands this properly when meeting
ad> dependencies requires wa
Thanks!
I'll do what I can. One problem is that this works for me in 108 other
Makefile.am's, and every once in a while one of them stops working and I
have to say where each source file lives.
It is strange...
H
--
> Sorry for the delay.
>
> >>> "Harlan" == Harlan Stenn <[EMAIL PROTECTED]> wr
Sorry for the delay.
>>> "Harlan" == Harlan Stenn <[EMAIL PROTECTED]> writes:
[...]
Harlan> A subdir that had:
Harlan> Makefile.am:
Harlan> [EMAIL PROTECTED]@:@srcdir@/../common
Harlan> bin_PROGRAMS= foo
Harlan> and no other files in it used to automatically get foo.c from
Harlan> srcdi
>>> "adl" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes:
[...]
adl> [*] I think this is not accurate if you limit yourself Solaris
adl> or Tru64 Make. But I'm assuming you don't.
if you limit yourself _to_ Solaris and Tru64 Make.
--
Alexandre Duret-Lutz
therdir
>
> Harlan> and with 1.8 I am seein more places where this no longer works.
>
> Harlan> The documentation does not clearly state that
> Harlan> augmenting VPATH is wrong.
>
> Harlan> Is it wrong to use an "augmented" VPATH with automake?
h 1.8 I am seein more places where this no longer works.
Harlan> The documentation does not clearly state that
Harlan> augmenting VPATH is wrong.
Harlan> Is it wrong to use an "augmented" VPATH with automake?
Right now, yes. I don't know how it could have possibly worked
So in the past we have successfully created Makefile.am's that say:
[EMAIL PROTECTED]@:@srcdir@/other/dir
foo_SOURCES= filefromdot filefromotherdir
and with 1.8 I am seein more places where this no longer works.
The documentation does not clearly state that augmenting VPATH is wrong.
Thank you Bob, that suggestion worked.
Also, using $(srcdir) also worked.
John
- Original Message -
From: Bob Friesenhahn <[EMAIL PROTECTED]>
Date: Monday, December 22, 2003 10:04 am
Subject: Re: vpath builds and include paths
> On Mon, 22 Dec 2003 [EMAIL PROTECT
Bob Friesenhahn wrote:
On Mon, 22 Dec 2003 [EMAIL PROTECTED] wrote:
However, if I want to build in a separate build tree (relying on
VPATH), then I try the following:
mkdir /build
cd /build
/test/configure
make
This attempts to build in this new /build directory, but during
compilation it
On Mon, 22 Dec 2003 [EMAIL PROTECTED] wrote:
> However, if I want to build in a separate build tree (relying on
> VPATH), then I try the following:
>
> mkdir /build
> cd /build
> /test/configure
> make
>
> This attempts to build in this new /build directory, but dur
On Mon, 2003-12-22 at 06:55, [EMAIL PROTECTED] wrote:
> The contents of /test/project1/sublevel/src/Makefile.am is:
>
> INCLUDE = -I../inc
> This attempts to build in this new /build directory, but during
> compilation it cannot locate the header file, myproj.hpp, and the rest
> of the bu
/project1/sublevel/src).
However, if I want to build in a separate build tree (relying on
VPATH), then I try the following:
mkdir /build
cd /build
/test/configure
make
This attempts to build in this new /build directory, but during
compilation it cannot locate the header file, myproj.hpp, and the
On Sun, Dec 07, 2003 at 09:24:30AM -0600, Bob Friesenhahn wrote:
On Sun, 7 Dec 2003, John Darrington wrote:
> Is there any way to instruct automake to only use relative pathnames
> in its makefile? This way, one could actually use the VPATH feature,
> which is
On Sun, 7 Dec 2003, John Darrington wrote:
> Is there any way to instruct automake to only use relative pathnames
> in its makefile? This way, one could actually use the VPATH feature,
> which is essential if you're building a project under certain CM
> systems.
In conjunct
Is there any way to instruct automake to only use relative pathnames
in its makefile? This way, one could actually use the VPATH feature,
which is essential if you're building a project under certain CM
systems.
J'
--
PGP Public key ID: 1024D/2DE827B3
fingerprint = 8797 A26D 0854
lot of .bmp example files. If I run
>
> David> automake ; autoconf ; configure ; make distclean ; configure ; make
> David> distcheck
>
> David> The 'make distcheck' always fails, with the error message:
>
> David> ERROR: distcleancheck can only r
nf ; configure ; make distclean ; configure ; make
David> distcheck
David> The 'make distcheck' always fails, with the error message:
David> ERROR: distcleancheck can only run from a VPATH build
There is no such message in your output. If there were, `make'
would have st
rror message:
ERROR: distcleancheck can only run from a VPATH build
then says:
ERROR: files left in build directory after distclean:
followed by a list of files.
However, those files are in 'EXTRA_DIST' so I would have thought the
fact they are distributed, automake would not try to remove them w
>>> "Harlan" == Harlan Stenn <[EMAIL PROTECTED]> writes:
Harlan> I find that automake-1.7* (at least) complains about lines like:
Harlan> if COND_FOO
Harlan> VPATH=$(srcdir):$(srcdir)/../foo
Harlan> endif
Harlan> in Makefile.am's (VPATH was alre
I find that automake-1.7* (at least) complains about lines like:
if COND_FOO
VPATH=$(srcdir):$(srcdir)/../foo
endif
in Makefile.am's (VPATH was already defined in condition TRUE, which implies
COND_FOO).
Bug or feature?
H
.html says pretty
clearly that VPATH isn't supported, so I'm not sure what's the best
thing to do. For other places where it's pretty obvious where the
sources lie, I've used $(processor)/filename, but in a number of cases I
need to pick the one up from the generic directory.
On Thu, 2002-08-15 at 02:01, Tom Tromey wrote:
> >>>>> ">" == leiming xd <[EMAIL PROTECTED]> writes:
>
> >> In win32 platforms ,the path of one file can include blank
> >> characters,I want to know how to add this path in the vpa
>>>>> ">" == leiming xd <[EMAIL PROTECTED]> writes:
>> In win32 platforms ,the path of one file can include blank
>> characters,I want to know how to add this path in the vpath.
I imagine it may not be possible. If it can work, autoconf needs t
must put the object correctly as it
is beeing called for resolving the specific object file including
directory path.
What I can accept is that there most likely is make versions out there
who cannot deduce the source path given an implicit rule and a path to a
object file outside the current directory
D'oh!
- Original Message -
From: "Robert Collins" <[EMAIL PROTECTED]>
> 2) Only emit explicit rules when the sources ARE in the same relative
^^^
NOT
> dir in the source tree. (Note: I haven'
Sumamry for automake:
automake 1.5 with VPATH builds using the Sun make environment and
subdirectory sources and SUBDIR_OBJECTS is failing due to partial
pattern replacement by the Sun make on the explicit .c.o rule. The
implicit rule works fine.
I'm happy to prep a patch for this, but whi
%% Regarding Use of vpath to build objects in separate directories;
%% Brian Appel <[EMAIL PROTECTED]> writes:
ba> I know vpath can be used to cause object files to be written to a
ba> directory tree separate from the original source.
No, it can't.
ba> In fact, if I
Hi. I'm a beginning autoconf/automake user.
I know vpath can be used to cause object files to be written to a directory
tree separate from the original source.
In fact, if I run configure in my separate destination directory, it builds
Makefiles there and I can perform the make there. Ho
"Derek R. Price" wrote:
> Akim Demaille wrote:
>
> > VPATH is just set to srcdir? So then, I'm in favor of Derek's patch
> > which seems finer that the current one, and updating the Autoconf
> > documentation to explain exactly what happens.
>
>
1 - 100 of 111 matches
Mail list logo
