Hi folks,
The targets in BUILT_SOURCES are unconditionally built for
'make all' and 'make install' and 'make check'. Very clumsy.
I would like to generate some code for an optional convenience
library exactly when needed.
Would there be a way to introduce a derived variable
libmylib_a_PREDEPEND
On March 31, 2005 07:56, [EMAIL PROTECTED] wrote:
(*) Hence you don't have to write #include ../include/inc.h in
main.c, but rather #include inc.h, and you can simply write
#include built.h, no matter if built.h is generated or not.
Sure, that would work except I can't modify the code
includes inc.h this way:
#include ../include/inc.h
and inc.h includes built.h this way:
#include built.h
Now, my src/Makefile.am contains something like this:
BUILT_SOURCES = ../include/built.h
../include/built.h:
mkdir -p $(@D)
touch $@
Everything works fine as long as I am
and inc.h in include. main.c includes inc.h this way:
#include ../include/inc.h
and inc.h includes built.h this way:
#include built.h
Now, my src/Makefile.am contains something like this:
BUILT_SOURCES = ../include/built.h
../include/built.h:
mkdir -p $(@D)
touch $@
Everything
BUILT_SOURCES = built.h
built.h: ../include/built.h
rm -f $@ $(LN_S) ../include/built.h $@
or easier, you have in the Makefile.am one level higher up:
BUILT_SOURCES = include/built.h
include/built.h:
$(mkdir_p) include
touch $@
for srcdir in $(some_dirs); do \
cd
Hi,
I am compiling a project with a swig generated file. Swig is a tool that
takes a foo.i file and generates a foo_wrap.cxx (it can do more but no
our concerne here ;-)).
In my Makefile.am, I put:
line 1: foo_wrap.cxx: foo.i
line 2: $SWIG -c++ -python foo.i
line 3:
line 4: BUILT_SOURCES
Hi Xavier,
On Sat, 07 Aug 2004 16:00:39 +0200, Xavier Dcoret wrote:
...
line 4: BUILT_SOURCES: foo_wrap.cxx
line 5: libfoo.la_SOURCES: foo_wrap.cxx
line 6:
line 7: dist_data_DATA: foo.i
...
Second question: The problem is that foo_wrap.cxx gets distributed too.
And since it is always more
:
Xavier line 1: foo_wrap.cxx: foo.i
Xavier line 2: $SWIG -c++ -python foo.i
Xavier line 3:
Xavier line 4: BUILT_SOURCES: foo_wrap.cxx
Xavier line 5: libfoo.la_SOURCES: foo_wrap.cxx
Xavier line 6:
Xavier line 7: dist_data_DATA: foo.i
This should be something like
foo_wrap.cxx: $(srcdir)/foo.i
Jan == Jan Kratochvil [EMAIL PROTECTED] writes:
Jan Hi Xavier,
Jan On Sat, 07 Aug 2004 16:00:39 +0200, Xavier Décoret wrote:
Jan ...
line 4: BUILT_SOURCES: foo_wrap.cxx
line 5: libfoo.la_SOURCES: foo_wrap.cxx
line 6:
line 7: dist_data_DATA: foo.i
Jan ...
Second question
On Sun, 2004-01-04 at 14:59, Warren Turkal wrote:
I have the following in a Makefile.am, but the locale.alias.pre is not being
distributed. How do I fix that?
x11localedir = @X11_LOCALEDIR@
BUILT_SOURCES=locale.alias
CLEANFILES=locale.alias
x11locale_DATA=locale.alias
locale.alias
Hi all!
I'm found another bug or feature :) I have no solution for...
I have a project with BUILT_SOURCES defined, moreover it _must_ be builded
_before_ any source code will be compiled.
In projects without BUILT_SOURCES defined it is OK to type `make install' to
compile and install sources
- Original Message -
From: "Tom Tromey" [EMAIL PROTECTED]
Subject: Re: make dist and BUILT_SOURCES
"Robert" == Robert Collins [EMAIL PROTECTED]
writes:
Were they also listed in another foo_SOURCES variable?
That would cause them to end up in the dist.
Rob
- Original Message -
From: "Tom Tromey" [EMAIL PROTECTED]
To: "Akim Demaille" [EMAIL PROTECTED]
Cc: "Robert Collins" [EMAIL PROTECTED];
[EMAIL PROTECTED]
Sent: Friday, April 06, 2001 3:13 AM
Subject: Re: make dist and BUILT_SOURCES
"Akim" =
"Robert" == Robert Collins [EMAIL PROTECTED] writes:
BUILT_SOURCES aren't automatically distributed.
Robert Well... it was trying to :]. I've sent in an extract from
Robert Makefile.am,, would you like a test case?
Sure.
Were they also listed in another foo_SOURCES variable?
- Original Message -
From: "Tom Tromey" [EMAIL PROTECTED]
To: "Robert Collins" [EMAIL PROTECTED]
Cc: "Akim Demaille" [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Friday, April 06, 2001 9:43 AM
Subject: Re: make dist and BUILT_SOURCES
"Robert" ==
files. (Some of them
Robert shouldn't be included in the distribution, and some can be).
Robert is there some way to exclude specific built sources from the
Robert disrtribution?
Automake will always ship parsers and scanners, but I don't believe it
ships all the BUILT_SOURCES.
Robert Some examp
Yet another question from the newbie.
I have a number of built source (.hand .c) files that are built from
other soources/configure settings.
"make dist" is failing to find these files. (Some of them shouldn't be
included in the distribution, and some can be).
is there some way to exclude
Hi,
I have seen a var which is BUILT_SOURCES.
Affecting this variable causes the make process build the var before
anything. (If I am wrong please tell me).
But is it necessary to build this var if the cmd is make clean ???
--
Florent DEVIN
"Florent" == Florent Devin [EMAIL PROTECTED] writes:
Florent I have seen a var which is BUILT_SOURCES.
Florent Affecting this variable causes the make process build the var before
Florent anything. (If I am wrong please tell me).
Florent But is it necessary to build this var if the c
"Braden" == Braden McDaniel [EMAIL PROTECTED] writes:
Tom I'd really like to find a better solution for the built files
Tom problem. This is currently too hard to do in automake.
Braden I ended up doing this:
Braden $(libfoo_la_OBJECTS): mybuiltheader.h
I recently changed how BUI
"Braden" == Braden McDaniel [EMAIL PROTECTED] writes:
I realize that BUILT_SOURCES is known to be problematic, but I haven't
found any other solution. Any suggestions?
Add explicit dependencies on it. There's no other way to ensure it's
generated. BUILT_SOURCES used to
On 14 Nov 2000, Alexandre Oliva wrote:
On Nov 14, 2000, Braden McDaniel [EMAIL PROTECTED] wrote:
I realize that BUILT_SOURCES is known to be problematic, but I haven't
found any other solution. Any suggestions?
Add explicit dependencies on it. There's no other way to ensure it's
On Nov 14, 2000, Braden McDaniel [EMAIL PROTECTED] wrote:
I realize that BUILT_SOURCES is known to be problematic, but I haven't
found any other solution. Any suggestions?
Add explicit dependencies on it. There's no other way to ensure it's
generated. BUILT_SOURCES used to work only
Currently, only original source files are deansified. Derived C
files, such as BUILT_SOURCES, are not deansified, even though the
corresponding _.o is expected. stat_.o is required, but the Makefile
doesn't know how to create it.
Is is safe to deansify all C source files, whether derived
I installed a new version of automake from CVS. I have the following
lines, among many others, in my Makefile.am:
AUTOMAKE_OPTIONS = ansi2knr
BUILT_SOURCES = lstat.c stat.c
It used to be that automake would create a Makefile.in which included
the following lines:
lstat_.c: lstat.c $(ANSI2KNR
On Mar 16, 2000, Tom Tromey [EMAIL PROTECTED] wrote:
"" == OKUJI Yoshinori [EMAIL PROTECTED] writes:
2. The target `Makefile' depends on $(BUILT_SOURCES).
The solution may be to get rid of the dependency in the item 2,
so my question is why Makefile must depend on BUI
"" == OKUJI Yoshinori [EMAIL PROTECTED] writes:
2. The target `Makefile' depends on $(BUILT_SOURCES).
The solution may be to get rid of the dependency in the item 2,
so my question is why Makefile must depend on BUILT_SOURCES. Is
there some good reason?
Only a hist
101 - 127 of 127 matches
Mail list logo
