* On 2025 25 Sep 13:41 -0500, Jan Engelhardt wrote:
>
> * diff produces a "line-by-line comparison" (terminology from the manpage).
> This is highly wasteful, because in the context of Makefile, we are only
> interested in a byte-by-byte comparison and stopping at the first mismatch.
> Use c
On Thursday 2025-09-25 19:31, Nate Bargmann wrote:
>> >hamlibdatetime.h: FORCE
>> >@if test -x $(top_srcdir)/.git ; then \
>> >echo "/* This date time is from the last non-merge commit to
>> > Hamlib. */" > $(builddir)/$(@F).tmp ;\
>> >echo "#define HAMLIBDATETIME "\"
echo "#define HAMLIBDATETIME "\"$$(TZ=UTC git
> > --git-dir=$(top_srcdir)/.git log --no-merges
> > --date='format-local:%Y-%m-%dT%H:%M:%SZ SHA=' --format='%cd' -n 1)$$(git
> > --git-dir=$(top_srcdir)/.git log --no-merges -n 1 | head -n 1 | cut
> >
* On 2025 24 Sep 14:15 -0500, Paul Smith wrote:
> On Wed, 2025-09-24 at 12:05 -0500, Nate Bargmann wrote:
> > As maintainer of the Hamlib project I am working on a reported issue
> > involving the installed version of make in the distribution. I have
> > verified the issue locally. The failure is
On Wed, 2025-09-24 at 12:05 -0500, Nate Bargmann wrote:
> As maintainer of the Hamlib project I am working on a reported issue
> involving the installed version of make in the distribution. I have
> verified the issue locally. The failure is:
>
> Making all in src
> make[1]: don't know how to ma
> --date='format-local:%Y-%m-%dT%H:%M:%SZ SHA=' --format='%cd' -n 1)$$(git
> --git-dir=$(top_srcdir)/.git log --no-merges -n 1 | head -n 1 | cut -c8-13)\"
> >> $(builddir)/$(@F).tmp ;\
The distinction is important.
>BUILT_SOURCES = $(builddir)/hamlibdateti
https://github.com/Hamlib/Hamlib/blob/master/src/Makefile.am)
there is the line:
BUILT_SOURCES = $(builddir)/hamlibdatetime.h
hamlibdatetime.h is also first in the variable that holds all of the
source files for this directory.
Further down is the rule:
# If we have a .git directory t
the dist.
>
> `EXTRA_DIST` only goes so far. In my own project I use `dist-hook` to
> bundle up foreign subdirectories which I am too lazy to fully describe
> or which are too fluid to bake into Makefile.am. For example:
I don't really have a problem with the distribution c
On Wed, 18 Sep 2019, Jerry Lundström wrote:
With v1.16 this step is executed during `make dist` and using
`EXTRA_DIST` for that whole directory would also mean that _the built
library_ would be included in the dist.
`EXTRA_DIST` only goes so far. In my own project I use `dist-hook` to
bundle
y that needs to be built
before I can start building my software, this library is included in the
project and I run a simple `cd dir && make` in it.
With v1.16 this step is executed during `make dist` and using
`EXTRA_DIST` for that whole directory would also mean that _the built
library
Hi Jerry,
On 9/17/19, Jerry Lundström wrote:
> This problem seems to have been introduced in v1.16 with:
>
> - "./configure && make dist" no longer fails when a distributed file
> depends on one from BUILT_SOURCES.
>
> And what I can see in the Makefile output
On Tue, 17 Sep 2019, Jerry Lundström wrote:
I can't really see how this change got approved, isn't the point of
BUILT_SOURCES to be sources built when building!? Including them into
distributions seems wrong.
I see considerable documentation regarding BUILT_SOURCES at
"http
Hi,
This problem seems to have been introduced in v1.16 with:
- "./configure && make dist" no longer fails when a distributed file
depends on one from BUILT_SOURCES.
And what I can see in the Makefile output is that $(BUILT_SOURCES) has
been added to distdir.
I can't rea
On Tue, Nov 28, 2017 at 8:35 PM, Nick Bowler wrote:
> On 2017-11-28 18:13 -0800, Jim Meyering wrote:
>> On Tue, Nov 28, 2017 at 12:45 PM, Nick Bowler wrote:
>> > The Automake manual unequivocally states that BUILT_SOURCES files are
>> > generated only when running
On 2017-11-28 18:13 -0800, Jim Meyering wrote:
> On Tue, Nov 28, 2017 at 12:45 PM, Nick Bowler wrote:
> > The Automake manual unequivocally states that BUILT_SOURCES files are
> > generated only when running 'make all', 'make check' or 'make install'.
On Tue, Nov 28, 2017 at 12:01 PM, Mathieu Lirzin wrote:
> Hello Jim,
...
>>
>> Here's the patch I expect to push to master:
...
>
> OK to push.
Thanks. Pushed.
I have also removed the micro branch.
On Tue, Nov 28, 2017 at 12:45 PM, Nick Bowler wrote:
> Hi Jim,
>
> On 2017-11-28 11:21 -0800, Jim Meyering wrote:
>> Date: Thu, 20 Mar 2014 12:31:32 -0700
>> Subject: [PATCH] "make dist" did not depend on $(BUILT_SOURCES)
>>
>> * lib/am/distd
Hi Jim,
On 2017-11-28 11:21 -0800, Jim Meyering wrote:
> Date: Thu, 20 Mar 2014 12:31:32 -0700
> Subject: [PATCH] "make dist" did not depend on $(BUILT_SOURCES)
>
> * lib/am/distdir.am (distdir-am): New intermediate target.
> Interpose this target between $(distdir
Jim Meyering
> Date: Thu, 20 Mar 2014 12:31:32 -0700
> Subject: [PATCH] "make dist" did not depend on $(BUILT_SOURCES)
>
> * lib/am/distdir.am (distdir-am): New intermediate target.
> Interpose this target between $(distdir) and its dependency
> on $(DISTFILES), so
is:
src/hello.c:27:10: fatal error: configmake.h: No such file or directory
#include "configmake.h"
^~
Here's the patch I expect to push to master:
From: Jim Meyering
Date: Thu, 20 Mar 2014 12:31:32 -0700
Subject: [PATCH] "make dist" did no
Hello,
I am porting a library from a recursive make to a non recursive one.
This library must generate c files wit ha tool named
"ender_generator", using BUILT_SOURCES
I have that directory structure:
Makefile.am
data/
dom/
Makefile.mk
svg/
Makefile.mk
esvg_private
Hi!
Shouldn’t TAGS depend upon and use BUILT_SOURCES?
For example, header files generated by yacc/bison may include things
that one would want tagged.
On Thu, Jun 21, 2012 at 7:20 AM, Timothy Madden wrote:
> Hello
>
> I have automake 1.11.1 (on CentOS 6.2 x86_64), and a Makefile.am like this:
>
> AM_YFLAGS=-d
> BUILT_SOURCES=position.hh location.hh code-formatter-parser.hh stack.hh
> bin_PROGRAMS=code-formatter
> cod
Hello
I have automake 1.11.1 (on CentOS 6.2 x86_64), and a Makefile.am like this:
AM_YFLAGS=-d
BUILT_SOURCES=position.hh location.hh code-formatter-parser.hh stack.hh
bin_PROGRAMS=code-formatter
code_formatter_SOURCES=code-formatter-parser.yy code-formatter-lexer.ll
apdump cmap_cns.h $(some files)
$(some files) are just a list of files needed to generate the header file
3) I compile mupdf stuff using cmap_cns.h.
I do that in mylib/mupdf-0.9/Makefile.am (points 1 and 2 only):
[code]
noinst_PROGRAMS = cmapdump fontdump
BUILT_SOURCES = cmapdump cmap
* Vincent Torri wrote on Mon, Nov 22, 2010 at 10:44:31PM CET:
> On Mon, 22 Nov 2010, Ralf Wildenhues wrote:
> >* Dave Hart wrote on Mon, Nov 22, 2010 at 12:34:47AM CET:
> >>In that case you may need to add cmap_tounicode.c to BUILT_SOURCES,
> >>leaving cmapdump out of
t use BUILT_SOURCES, cmapdump binary is not built before
libcmaps, hence cmap_tounicode.c is not created, and compilation of
libcmaps fails.
Is there another solution ?
Yes: just specify cmapdump$(EXEEXT) as prerequisite to cmap_tounicode.c.
isn't what the line:
cmap_tounicode.c
* Dave Hart wrote on Mon, Nov 22, 2010 at 12:34:47AM CET:
> On Sun, Nov 21, 2010 at 22:44 UTC, Vincent Torri wrote:
> > On Sun, 21 Nov 2010, Ralf Wildenhues wrote:
> >> * Vincent Torri wrote on Sun, Nov 21, 2010 at 11:14:23PM CET:
> >>> If I don't use BUILT_SO
On Sun, Nov 21, 2010 at 22:44 UTC, Vincent Torri wrote:
> On Sun, 21 Nov 2010, Ralf Wildenhues wrote:
>> * Vincent Torri wrote on Sun, Nov 21, 2010 at 11:14:23PM CET:
>>> If I don't use BUILT_SOURCES, cmapdump binary is not built before
>>> libcmaps, hence cmap
-0.7/cmaps/Adobe-CNS1-UCS2 \
[...]
libcmaps_la_SOURCES = cmap_tounicode.c
cmap_tounicode.c: cmapdump $(cmap_tounicode_files)
./cmapdump $@ $(cmap_tounicode_files)
If I don't use BUILT_SOURCES, cmapdump binary is not built before
libcmaps, hence cmap_tounicode.c is not created
ps/Adobe-CNS1-UCS2 \
[...]
> libcmaps_la_SOURCES = cmap_tounicode.c
> cmap_tounicode.c: cmapdump $(cmap_tounicode_files)
> ./cmapdump $@ $(cmap_tounicode_files)
>
> If I don't use BUILT_SOURCES, cmapdump binary is not built before
> libcmaps, hence cmap_tounicode.c is not cre
On Sun, 21 Nov 2010, Ralf Wildenhues wrote:
Hello Vincent,
* Vincent Torri wrote on Sun, Nov 21, 2010 at 10:51:53PM CET:
noinst_PROGRAMS = cmapdump fontdump
BUILT_SOURCES = cmapdump fontdump
With MSYS, noinst_PROGRAMS is set to
cmapdump$(EXEEXT) fontdump$(EXEEXT)
but BUILT_SOURCES is set
Hello Vincent,
* Vincent Torri wrote on Sun, Nov 21, 2010 at 10:51:53PM CET:
> noinst_PROGRAMS = cmapdump fontdump
> BUILT_SOURCES = cmapdump fontdump
>
> With MSYS, noinst_PROGRAMS is set to
>
> cmapdump$(EXEEXT) fontdump$(EXEEXT)
>
> but BUILT_SOURCES is set to
>
Hey,
I use:
noinst_PROGRAMS = cmapdump fontdump
BUILT_SOURCES = cmapdump fontdump
With MSYS, noinst_PROGRAMS is set to
cmapdump$(EXEEXT) fontdump$(EXEEXT)
but BUILT_SOURCES is set to
cmapdump fontdump
Is it normal that BUILT_SOURCES does not try to see if they are binaries
in some
> Weird. I cannot reproduce your issue with that make version on
> GNU/Linux.
>
> Which file system does this happen on, maybe a case-insensitive one and
> there is another file in the source or the build tree matching the name
> (or parts of the dirname) case-insensitively?
Great tip! I forgot
* Daily, Jeff A wrote on Tue, Aug 10, 2010 at 11:29:42PM CEST:
> Sorry for missing that. GNU Make 3.81 built for i386-apple-darwin9.0.
Weird. I cannot reproduce your issue with that make version on
GNU/Linux.
Which file system does this happen on, maybe a case-insensitive one and
there is anoth
> > > Which make version and implementation,
>
> Please answer this one as well.
Sorry for missing that. GNU Make 3.81 built for i386-apple-darwin9.0.
* Daily, Jeff A wrote on Tue, Aug 10, 2010 at 09:45:43PM CEST:
> > Which make version and implementation,
Please answer this one as well.
> > #*snip*
> > BUILT_SOURCES =
> > lib_LTLIBRARIES = libfoo.la
> > libfoo_la_SOURCES =
> > #*snip*
> > If HAVE_PYTHON
> > BUILT_SOURCES += foo/bar/wapi.c
> > foo/bar/wapi.c: foo/bar/papi.h $(top_srcdir)/build-aux/wapi.py
> > -rm -f
Hi Jeff,
* Daily, Jeff A wrote on Tue, Aug 10, 2010 at 08:54:53PM CEST:
> I am using subdir-objects and I have a single, top-level Makefile.am:
>
> #*snip*
> BUILT_SOURCES =
> lib_LTLIBRARIES = libfoo.la
> libfoo_la_SOURCES =
> #*snip*
> If HAVE_PYTHON
> BUILT_SOURCES
I have almost the same situation as a post many years ago. The solution didn't
seem to apply, however,
http://www.opensubscriber.com/message/automake@gnu.org/3498366.html
I am using subdir-objects and I have a single, top-level Makefile.am:
#*snip*
BUILT_SOURCES =
lib_LTLIBRARIES = libf
On Thu, Mar 11, 2010 at 14:42, Eric Blake wrote:
> How about modifying the makefiles that don't append to BUILT_SOURCES to
> just add the line
>
> BUILT_SOURCES=
>
> prior to the include, then use BUILT_SOURCES+= in the included file.
Of course, great idea! Thanks!
Cheers
Adam
On 03/11/2010 01:39 PM, Adam Mercer wrote:
> include path/to/Makefile.common
>
> The problem is that some Makefile.am's already define BUILT_SOURCES,
> whilst some do not. Is there a way that I can append to BUILT_SOURCES,
> if it already exists, or define it if it doesn
Hi
For one of the projects I work on we need to add something like the
following to each Makefile.am to ensure that vcs information is
current:
vcsID:
cd $(top_builddir)/src/lalapps && $(MAKE) liblalapps.la
BUILT_SOURCES = vcsID
As this is going to be the same in each Makefile.am,
Hi Russell,
beside the typo you already found,
* Russell Shaw wrote on Thu, Dec 17, 2009 at 02:07:40PM CET:
> bin_PROGRAMS = appmain
>
> appmain_SOURCES = appmain.c
> nodist_appmain_SOURCES = gran.proc.tab.c
BUILT_SOURCES = gran.proc.tab.c
> gran.proc.tab.c: gran.spec
>
Simon Richter wrote:
Hi,
On Fri, Dec 18, 2009 at 12:07:40AM +1100, Russell Shaw wrote:
BUILT_SOURCES: gran.proc.tab.c
BUILT_SOURCES is a variable, not a target.
Ok Thanks Simon. Should be '=' instead of ':'.
I knew that, but i didn't type what i mean ;)
Hi,
BUILT_SOURCES has no effect. gran.proc.tab.c should be built
first, but it doesn't happen. eerat isn't even run:
bin_PROGRAMS = appmain
appmain_SOURCES = appmain.c
nodist_appmain_SOURCES = gran.proc.tab.c
BUILT_SOURCES: gran.proc.tab.c
gran.proc.tab.c: gran.spec
eerat
Hello Andre,
Your example is pretty complex, and doesn't make the problem obvious.
Merely adding libCustomPlugin.la to BUILT_SOURCES doesn't seem to
introduce a cycle in the build dependencies, at least from a 'make -n'
in an example package that has this Makefile.am but no
ot;.hpp" and some
> with ".h". So I must add some extra suffix rules...
>
> When I call "make libCustomPlugin.la && make qplugin" all things works
> correctly.
>
> "make all" can't build the project...
>
> I had gamble a littl
files. But when uic can't load the plugin my header is broken;()
Our source are bad organized, because there some file with ".hpp" and some
with ".h". So I must add some extra suffix rules...
When I call "make libCustomPlugin.la && make qplugin" all t
Hello Bobby,
a few comments:
On Sat, May 03, 2008 at 11:38:08PM -0700, Bobby Dill wrote:
> When I try to compile my app, I get a message stating that sigcreatedlg.h
> does not exist, so the files in BUILT_SOURCES are not generated before the
> rest of my app is compiled. What's th
"Bobby Dill" <[EMAIL PROTECTED]> writes:
> pkgmaker_UI =
> sigcreatedlg.h
> sigcreatedlg.cpp
One obvious error is here: the first two lines should end in \.
--
"[Modern] war is waged by each ruling group against its own subjects,
and the object of the war is not to make or prevent conqu
RCES = pkgmaker.cpp $(pkgmaker_UI)
BUILT_SOURCES = $(pkgmaker_UI)
# set the include path found by configure
INCLUDES= $(all_includes)
# the library search path.
pkgmaker_LDFLAGS = $(all_libraries)
pkgmaker_LDADD = ../dirlist/libdirlist.la
CLEANFILES = $(BUILT_SOURCES)
I get several warning when I run
Hello Benoit,
* Benoit Sigoure wrote on Fri, Mar 30, 2007 at 10:30:43PM CEST:
>
> I've searched in the manual but the following behavior is not documented:
[...]
> # Built sources are automatically removed by maintainer-clean.
> $clean_files{'$(BUILT_SOURCES)'}
Hello
I've searched in the manual but the following behavior is not documented:
# handle_clean ($MAKEFILE)
#
# Handle all 'clean' targets.
sub handle_clean ($)
{
...
# Built sources are automatically removed by maintainer-clean.
$clean_files{&
Hello,
On Tue, Mar 28, 2006 at 12:16:18PM +0200, Michael Biebl meant to write:
> EXTRA_DIST = ngcs_marshal.ngci idef.py ngcs.py
> CLEANFILES = ngcs_marshal.h ngcs_marshal.c
>
> ngcs_marshal.c: ngcs_marshal.ngci idef.py
> $(srcdir)/idef.py $(srcdir)/ngcs_marshal $@
>
> ngcs_marshal.h: ngc
Ralf Wildenhues wrote:
> Hi Michael,
>
> * Michael Biebl wrote on Tue, Mar 28, 2006 at 12:16:18PM CEST:
>> This is the solution I came up with:
>>
>> EXTRA_DIST = ngcs_marshal.ngci idef.py ngcs.py
>> CLEANFILES = ngcs_marshal.h ngcs_marshal.c
>>
>> ngcs_marshal.c: ngcs_marshal.ngci idef.py
>>
Hi Michael,
* Michael Biebl wrote on Tue, Mar 28, 2006 at 12:16:18PM CEST:
> This is the solution I came up with:
>
> EXTRA_DIST = ngcs_marshal.ngci idef.py ngcs.py
> CLEANFILES = ngcs_marshal.h ngcs_marshal.c
>
> ngcs_marshal.c: ngcs_marshal.ngci idef.py
> $(srcdir)/idef.py $(srcdir)/ng
Ralf Wildenhues wrote:
> Hi Michael, Tom,
Hi,
thanks for you help so far.
> * tom fogal wrote on Mon, Mar 27, 2006 at 10:38:27PM CEST:
>> <[EMAIL PROTECTED]>Michael Biebl writes:
>>
>>> ngcs_marshal.c: ngcs_marshal.ngci idef.py
>>>$(srcdir)/idef.py ngcs_marshal
>>>
>>> ngcs_marshal.h:
Hi Michael, Tom,
* tom fogal wrote on Mon, Mar 27, 2006 at 10:38:27PM CEST:
> <[EMAIL PROTECTED]>Michael Biebl writes:
>
> >ngcs_marshal.c: ngcs_marshal.ngci idef.py
> >$(srcdir)/idef.py ngcs_marshal
> >
> >ngcs_marshal.h: ngcs_marshal.ngci idef.py
> >$(srcdir)/idef.py ngcs_marsh
<[EMAIL PROTECTED]>Michael Biebl writes:
>ngcs_marshal.c: ngcs_marshal.ngci idef.py
>$(srcdir)/idef.py ngcs_marshal
>
>ngcs_marshal.h: ngcs_marshal.ngci idef.py
>$(srcdir)/idef.py ngcs_marshal
Not sure if it will work, but perhaps you could just use the .ngci file
without copying
I forgot to add that I'm not subscribed to the list so please CC on replies.
Cheers,
Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
= \
initng_ngcs.c \
initng_ngcs.h \
initng_ngcs_cmds.c \
initng_ngcs_cmds.h \
ngcs_common.h \
ngcs_marshal.c \
ngcs_marshal.h \
ngcs_paths.h
BUILT_SOURCES = ngcs_marshal.h
EXTRA_DIST = ngcs_marshal.ngci idef.py ngcs.py
ngcs_marshal.c: n
I wrote:
>> .fl.h:
>> d=`dirname [EMAIL PROTECTED] ; \
>> f=`basename $@ .h`.fl ; \
>> cp $< $(top_builddir)/$$d/$$f ; \
>> cd $(top_builddir)/$$d ; \
>> fluid -c $$f
>>
>> BUIL
On Mar 9, 2006, at 12:57 PM, Thomas Dickey wrote:
On Thu, 9 Mar 2006, Thomas 'Tom' R. Treadway III wrote:
On Mar 9, 2006, at 11:51 AM, Thomas Dickey wrote:
hmm - I can remember when it was a problem (around 1990), but can't
recall whether it was Apollo SR9, SunOS 3 or HPUX. You did say
"anc
On Thu, 9 Mar 2006, Thomas 'Tom' R. Treadway III wrote:
On Mar 9, 2006, at 11:51 AM, Thomas Dickey wrote:
hmm - I can remember when it was a problem (around 1990), but can't
recall whether it was Apollo SR9, SunOS 3 or HPUX. You did say
"ancient"...
The dirname utility originated in System III
On Mar 9, 2006, at 11:51 AM, Thomas Dickey wrote:
On Thu, 9 Mar 2006, Ralf Wildenhues wrote:
* Thomas Dickey wrote on Thu, Mar 09, 2006 at 08:13:07PM CET:
On Thu, 9 Mar 2006, Ralf Wildenhues wrote:
dirname and basename are not portable to ancient hosts. In
practice
they will work fine,
On Thu, 9 Mar 2006, Ralf Wildenhues wrote:
* Thomas Dickey wrote on Thu, Mar 09, 2006 at 08:13:07PM CET:
On Thu, 9 Mar 2006, Ralf Wildenhues wrote:
dirname and basename are not portable to ancient hosts. In practice
they will work fine, though. I'd write
I know that dirname is not, but wh
* Thomas Dickey wrote on Thu, Mar 09, 2006 at 08:13:07PM CET:
> On Thu, 9 Mar 2006, Ralf Wildenhues wrote:
>
> >dirname and basename are not portable to ancient hosts. In practice
> >they will work fine, though. I'd write
>
> I know that dirname is not, but what platform did not support basenam
On Thu, 9 Mar 2006, Ralf Wildenhues wrote:
dirname and basename are not portable to ancient hosts. In practice
they will work fine, though. I'd write
I know that dirname is not, but what platform did not support basename?
--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-islan
AIL PROTECTED] ; \
> f=`basename $@ .h`.fl ; \
> cp $< $(top_builddir)/$$d/$$f ; \
> cd $(top_builddir)/$$d ; \
> fluid -c $$f
>
> BUILT_SOURCES += src/foo.h
>
> nodist_src_libfoo_a_SOURCES = src/foo.cxx
>
Alexandre Duret-Lutz <[EMAIL PROTECTED]> wrote:
> lots of helpful things...
Thanks. I will look into your suggestions this evening.
No doubt you have noticed that I reposted a more up to date version
of src/Makefile.am that does handle some of these problems better,
and I have made even further p
g/archive/html/automake/2006-02/msg00036.html)
However, it's taken me several evenings of experimentation, not to
mention frustration, to try to marry the BUILT_SOURCES needed for the
two stage build with the non-recursive auto{conf,make} configuration,
and also be able to run 'configure' a
gt; fluid -c $<
DG> .fl.cxx:
DG> fluid -c $<
DG> BUILT_SOURCES += src/foo.h
DG> src_libfoo_a_SOURCES = src/foo.fl
DG> src_foo_test_LDADD = src/libfoo.a $(FLTK_LIBRARYS)
DG> src_foo_test_LDFLAGS = $(FLTK_LDSFLAGS)
DG> src_foo_test_SOURCES = src/fo
I was given help two weeks ago in the thread "Autoconfisticating a
multi-directory, non-recursive, GNU-make specific project"
(see http://lists.gnu.org/archive/html/automake/2006-02/msg00036.html)
Three years ago on this list, I was helped with BUILT_SOURCES in the
thread "How to
>
>Could you modify it so that it fails for you?
>
I updated my automake 1.6 to automake 1.9 and I autoreconfigured all. It
works well now. Thanks for your help.
Hi Kototama,
* Kototama wrote on Mon, Feb 20, 2006 at 08:23:34PM CET:
>
> I added the header file generated by automake/bison in BUILT_SOURCES but
> when I type make automake doesn't invoke bison to generate the header
> file from the corresponding .ypp file.
I cannot repr
Hi all.
If that helps, this is how I use Flex & Bison with Automake :
http://cvs.sourceforge.net/viewcvs.py/yaorb/yaorb/src/cpp/dev/idlc/Makefile.am?only_with_tag=MAIN&view=markup
-- Marc.
Kototama wrote:
Hi,
I added the header file generated by automake/bison in BUILT_SOURCES bu
Hi,
I added the header file generated by automake/bison in BUILT_SOURCES but
when I type make automake doesn't invoke bison to generate the header
file from the corresponding .ypp file.
In the meantime I have patched automake, e.g.
diff -ur automake-1.9.5/lib/am/library.am automake-1.9.5.new/lib/am/library.am
--- automake-1.9.5/lib/am/library.am2003-06-02 09:08:40.0 +0200
+++ automake-1.9.5.new/lib/am/library.am 2005-05-22 20:22:51.0 +0200
@@ -15,6 +15,7 @@
Hi,
On Sun, May 22, 2005 at 05:02:09PM +0200, Harald Dunkel wrote:
> The targets in BUILT_SOURCES are unconditionally built for
> 'make all' and 'make install' and 'make check'. Very clumsy.
yes, it is. Yet it can be useful in certain situations.
> I
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
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 , and you can simply write
> #include , no matter if built.h is generated or not.
Sure, that would work except I can't modify the code itself b
is way:
Simon> #include "built.h"
Simon> Now, my src/Makefile.am contains something like this:
Simon> BUILT_SOURCES = ../include/built.h
Simon> ../include/built.h:
Simon> mkdir -p $(@D)
Simon> touch $@
Simon> Everything works fine as long as I am building in the
I should modify all
> the files including the built headers so that they point to the central
> directory?
No, why? Automake puts `-I.' in AM_CPPFLAGS. After you ensure that
../include/built.h exists, you have in Makefile.am
BUILT_SOURCES = built.h
built.h: ../include
On Wed, 30 Mar 2005, Simon Perreault wrote:
On March 30, 2005 10:44, Ralf Wildenhues wrote:
#include "../include/inc.h"
which is not portable, by the way (but I can see if you don't care about
that part of the world).
Why do you say that? That code is being ported from Microsoft's compiler,
and
I
On March 30, 2005 10:44, Ralf Wildenhues wrote:
> > #include "../include/inc.h"
>
> which is not portable, by the way (but I can see if you don't care about
> that part of the world).
Why do you say that? That code is being ported from Microsoft's compiler, and
I guess that if it works there and
ut I can see if you don't care about
that part of the world).
> 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 -
On March 30, 2005 10:14, Gary V. Vaughan wrote:
> AM_CPPFLAGS = -I$(top_srcdir)/include -I$(top_builddir)/include
Sure, this fixes the problem given in my example. But I can't do that because
of this:
> > The quick fix is to add the location of inc.h, prefixed with
> > $(top_builddir). However
" and "include". I place main.c in src
> 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
src
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)
>>> "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:
&
;-)).
Xavier> In my Makefile.am, I put:
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>
Hi Xavier,
On Sat, 07 Aug 2004 16:00:39 +0200, Xavier Décoret 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.
&g
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
I see that the "install" target now depends on BUILT_SOURCES. This is Good.
I have a different problem.
I have a pre-built dynamic library that gets checked in to the tree.
Don't ask, it's really a feature.
So I have a Makefile.am that contains:
BUILT_SOURCES=
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
>
>
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: locale.alias.pre
$(CPP) -traditional - < $< >
Hi,
I found a problem running `make install' in my project.
It contain generation of valued file (needed to success compile sources) as
BUILT_SOURCES definition. Targes such as `all' and `check' work fine, except
`install', becouse it is not depended on $(BUILT_SOURCE
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 insta
1 - 100 of 126 matches
Mail list logo
