Jacob Bachmeyer wrote:
[...] The preliminary reports that it was an RCE backdoor that would
pass commands smuggled in public key material in SSH certificates to
system(3) (as root of course, since that is sshd's context at that
stage) are inconsistent with the slowdown that caused the backdoor
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> However, the question remains unanswered why it needs 3 different
> compression
that, and ended up getting
xz-utils targeted as a means of getting to sshd without the OpenSSH
maintainers noticing.
The systemd people are working on reducing the libsystemd dependencies:
https://github.com/systemd/systemd/issues/32028
However, the question remains unanswered why it needs 3
, and ended up getting
> xz-utils targeted as a means of getting to sshd without the OpenSSH
> maintainers noticing.
The systemd people are working on reducing the libsystemd dependencies:
https://github.com/systemd/systemd/issues/32028
However, the question remains unanswered why it n
Bob Friesenhahn writes:
> In my opinion, convenience libraries are evil (they dramatically slow
> down the build) and it is better to use a non-recursive build, using
> Makefile variables to list the required object files in the link rather
> than using a convenience library.
The only annoyance
On Wed, 21 May 2014, Zé wrote:
Is there a way to specify dependencies between convenience libraries, and
also set the relevant include paths?
Convenience libraries do not have normal dependencies because they are
not used as libraries (they are just bundled object files). However,
you can
Is there a way to specify dependencies between convenience libraries,
and also set the relevant include paths?
Thanks,
Zé
openvswitch should tell you what its dependencies are.
On Sat, Sep 28, 2013 at 7:37 PM, Ferenc Cserepkei wrote:
> Welcome,
> I'm doing jenkins build of openvswitch-1.11 on a centos 6.4 amd64 host.
> Openvswitch coming from git repo has a boot.sh scrit contains command
> aut
Welcome,
I'm doing jenkins build of openvswitch-1.11 on a centos 6.4 amd64 host.
Openvswitch coming from git repo has a boot.sh scrit contains command
autoreconf --install --force
since OVS requires autoconf 2.64+ i have compiled latest autmake, autoconf
and libtool, but still have problems with t
On Sep 16, 2013, at 11:38 PM, Xochitl Lunde wrote:
>
> On Sep 16, 2013, at 4:52 PM, Nate Bargmann wrote:
>
>>> * On 2013 15 Sep 13:18 -0500, Jules Colding wrote:
>>
So, how do I tell the top-level Makefile.am that it should traverse all
sub-directories building only the libraries,
Jules Colding writes:
> Anyways, thanks for the advises. I'll read the paper on evil
> recursiveness and ponder what to do.
"Non-recursive make" is indeed a nice paradigm for various reasons,
but if you've read earlier threads on this list, actually
_implementing_ it is not quite that trivial.
Y
;Cc: automake@gnu.org
>Subject: Re: Problem with circular dependencies
On Sep 16, 2013, at 4:52 PM, Nate Bargmann wrote:
>> * On 2013 15 Sep 13:18 -0500, Jules Colding wrote:
>
>>> So, how do I tell the top-level Makefile.am that it should traverse all
>>> sub-directo
On Sep 16, 2013, at 4:52 PM, Nate Bargmann wrote:
> * On 2013 15 Sep 13:18 -0500, Jules Colding wrote:
>
>> So, how do I tell the top-level Makefile.am that it should traverse all
>> sub-directories building only the libraries, and then traverse the
>> sub-directories again building only the
* On 2013 15 Sep 13:18 -0500, Jules Colding wrote:
> So, how do I tell the top-level Makefile.am that it should traverse all
> sub-directories building only the libraries, and then traverse the
> sub-directories again building only the test applications?
Would it work to break the test program
On 09/15/2013 11:12 PM, Diego Elio Pettenò wrote:
On Sun, Sep 15, 2013 at 7:16 PM, Jules Colding wrote:
So, how do I tell the top-level Makefile.am that it should traverse all
sub-directories building only the libraries, and then traverse the
sub-directories again building only the test applic
On Sun, Sep 15, 2013 at 7:16 PM, Jules Colding wrote:
>
> So, how do I tell the top-level Makefile.am that it should traverse all
> sub-directories building only the libraries, and then traverse the
> sub-directories again building only the test applications?
>
You don't.
This is one of the reas
Hi,
I have set of subdirectories here:
https://github.com/colding/MercuryFIX/tree/master/applib
They all have Makefile.am files.
The top-level automake file lists 4 subdirectories. Only the fixio and fixmsg
directories are interesting in this case.
fixio and fixmsg both builds static libra
On 02/11/2012 16:16, Václav Zeman wrote:
> How can I make this work as you have suggested without $(top_builddir)?
Okay here's my rule of thumb (Stefano can give you the informed,
developer opinion):
- if it's declared in the same makefile, don't use $(top_builddir);
- if it's declared on a dif
On 11/02/2012 09:43 AM, Stefano Lattarini wrote:
> On 11/02/2012 09:18 AM, Václav Zeman wrote:
>> On 1 November 2012 17:42, Diego Elio Pettenò wrote:
>>> On 01/11/2012 09:18, Vincent Torri wrote:
lib_eo_libeo_la_LIBADD = $(top_builddir)/src/lib/eina/libeina.la
>>>
>>> Don't use $(top_builddir)
On 11/02/2012 09:18 AM, Václav Zeman wrote:
> On 1 November 2012 17:42, Diego Elio Pettenò wrote:
>> On 01/11/2012 09:18, Vincent Torri wrote:
>>> lib_eo_libeo_la_LIBADD = $(top_builddir)/src/lib/eina/libeina.la
>>
>> Don't use $(top_builddir) and it should work just fine.
> Is there a rationale be
On 1 November 2012 17:42, Diego Elio Pettenò wrote:
> On 01/11/2012 09:18, Vincent Torri wrote:
>> lib_eo_libeo_la_LIBADD = $(top_builddir)/src/lib/eina/libeina.la
>
> Don't use $(top_builddir) and it should work just fine.
Is there a rationale behind this? I am not saying it is wrong, I just
want
On 01/11/2012 09:18, Vincent Torri wrote:
> lib_eo_libeo_la_LIBADD = $(top_builddir)/src/lib/eina/libeina.la
Don't use $(top_builddir) and it should work just fine.
--
Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/
to make target `../src/lib/eina/libeina.la',
needed by `lib/eo/libeo.la'. Stop.
make[3]: *** Waiting for unfinished jobs
I thought that adding in the LIBADD primary libeina.la was sufficient
to deal with dependencies, but it seems that it is not.
What should I add to correctly manage d
On 06/28/2012 01:25 PM, David Sveningsson wrote:
>
>>> app_SOURCES = test.foo main.c
>>
>> I'm not sure how well listing the .foo file in _SOURCES is going to
>> work, although someone who knows more about automake guts might be able
>> to tell us exactly what happens. You should probably list
On 06/27/2012 10:47 PM, Nick Bowler wrote:
> Hello David,
>
> On 2012-06-27 18:13 +0200, David Sveningsson wrote:
>> I'm having some problems when generating source files. I have written a
>> tool which generates both a c source-file, a header and dependencies of
>
Hello David,
On 2012-06-27 18:13 +0200, David Sveningsson wrote:
> I'm having some problems when generating source files. I have written a
> tool which generates both a c source-file, a header and dependencies of
> the source, all at the same time using a single command.
Ther
Hi,
I'm having some problems when generating source files. I have written a
tool which generates both a c source-file, a header and dependencies of
the source, all at the same time using a single command.
After stripping of the flags my rules basically look like this:
SUFFIXES =
[Adding the Automake list in CC:]
On 06/20/2012 09:57 PM, Jeff King wrote:
> On Wed, Jun 20, 2012 at 02:45:31PM -0500, Jonathan Nieder wrote:
>
>> Jeff King wrote:
>>
>>> Did you read the argument in patch 2? They are almost certainly not
>>> helping anyone, anyway.
>>
>> Yes, I read patch 2. I h
On Sunday 06 November 2011, Stefan wrote:
> OK, here is my Makefile.am, which at this point works.
> But it does not include the data dependency:
>
Yes, but we'd like to see the one that is failing, otherwise
how can we see what's wrong? :-)
> @SET_MAKE@
>
> ACLOCAL_AMFLAGS = -I share/misc/m4
>
Oh, and my Automake Version is 1.10.1.
Am 06.11.2011 um 10:14 schrieb Stefano Lattarini:
> On Saturday 05 November 2011, Stefan wrote:
>> Hi automake list!
>>
>> I'm trying to write a Makefile(.am) to make pdf plots from R scripts.
>> Hence the plot is depending on the script and the data. What
OK, here is my Makefile.am, which at this point works. But it does not include
the data dependency:
@SET_MAKE@
ACLOCAL_AMFLAGS = -I share/misc/m4
SUFFIXES = .R .pdf
noinst_PLOTS = R_Double_new.pdf sample_distris.pdf
noinst_DATA = R_Double_new.histo
noinst_R = R_Double_new.R sample_distris.R
no
On Saturday 05 November 2011, Stefan wrote:
> Hi automake list!
>
> I'm trying to write a Makefile(.am) to make pdf plots from R scripts.
> Hence the plot is depending on the script and the data. What I tried
> is:
>
> SUFFIXES = .R .data .pdf
>
> .R
> make R script executable
>
[Nit: doe
Hi automake list!
I'm trying to write a Makefile(.am) to make pdf plots from R scripts. Hence the
plot is depending on the script and the data. What I tried is:
SUFFIXES = .R .data .pdf
.R
make R script executable
.R.pdf:
Do stuff
.data.pdf:
Do the same stuff as for .R
ot
working on f90 as well.
- fabricio
-Original Message-
From: Jeff Squyres
Sent: Wednesday, July 13, 2011 3:06 PM
To: Dave Goodell
Cc: Nick Bowler ; automake@gnu.org
Subject: Re: fortran 77 header dependencies
On Jul 13, 2011, at 1:50 PM, Dave Goodell wrote:
Your correction of Jeff'
On Jul 13, 2011, at 1:50 PM, Dave Goodell wrote:
> Your correction of Jeff's solution made me realize that my "version 3"
> solution is wrong. It expresses a foo-->bar.h dependency instead of
> foo.o-->bar.h dependency. Your approach is what I was looking for.
> Unfortunately this solution g
On Jul 13, 2011, at 9:43 AM CDT, Nick Bowler wrote:
> On 2011-07-13 07:59 -0400, Jeff Squyres wrote:
>> On Jul 12, 2011, at 12:23 PM, Dave Goodell wrote:
>>> Is there a better way? I really expected version 2 to work and was
>>> surprised when it didn't.
>>
>> I've always a) assumed that Automak
(Disclaimer: I'm not familiar with Automake's Fortran support. The
following is based on the assumption that Fortran compilers work
in a similar manner to C compilers).
On 2011-07-13 07:59 -0400, Jeff Squyres wrote:
> On Jul 12, 2011, at 12:23 PM, Dave Goodell wrote:
> > Is there a better way? I
On Jul 13, 2011, at 10:43 AM, Nick Bowler wrote:
> So this would perhaps be better written as
>
> foo_obj = foo.$(OBJEXT) # might need to be foo.lo if using libtool.
> $(foo_obj): bar.h
You're completely correct, of course. I was typing from memory with neither
the proper amount of caffeine
On Jul 12, 2011, at 12:23 PM, Dave Goodell wrote:
> Is there a better way? I really expected version 2 to work and was surprised
> when it didn't.
I've always a) assumed that Automake doesn't have Fortran dependency analysis,
and b) coped with it by adding explicit dependency rules myself (whi
I'm curious what the recommended way to deal with fortran 77 header
dependencies is in automake. Assume that I've got two source files, "foo.f"
and "bar.h", that look like this (hopefully my mailer won't mangle the spacing
too badly):
foo.f:
8<
I am facing a problem with library and header dependencies among
autoconfiscated packages.
I will explain my problem based on a modified version of "arm and hand"
example package I got from "GNU Automake Manual", chapter 7.4 Nesting
Packages. Suppose that instead of having a
Hi,
I am facing a problem with nested packages which have mutual library and
header dependencies.
I will try to explain my problem based on some changes of the arm and hand
example, in 7.4 Nesting Packages, from GNU. Suppose that instead of having
arm and hand packages my project application has
On 2011-06-23 16:25 -0400, Jie Zhang wrote:
> > With Posix make Makefiles, it would be doable with some more work, but
> > automake doesn't. With GNU make extensions used in the Makefile.am, it
> > is almost impossible without implementing a large set of GNU make
> > extension parsing in automake
On Thu, Jun 23, 2011 at 4:51 PM, Nick Bowler wrote:
> On 2011-06-23 16:25 -0400, Jie Zhang wrote:
>> > With Posix make Makefiles, it would be doable with some more work, but
>> > automake doesn't. With GNU make extensions used in the Makefile.am, it
>> > is almost impossible without implementing
,
> and in this special case also unportable, as $< in non-inference rules
> requires GNU make.
>
Yeah, I agree. I saw that BFD in Binutils uses this method and thought
it might be the "standard" way to deal with this situation. It seems
we would better to use the undocumen
ne to bitrot as the automake-emitted
rules are improved over time (which is more likely than anything else),
and in this special case also unportable, as $< in non-inference rules
requires GNU make.
> The root cause of this issue is that Automake does not distinguish
> rules with commands
ake any distinction between rules with
>> commands and rules that only specify dependencies. So it is not
>> possible
>> to append new dependencies to an automake-defined target without
>> redefining the entire rule.
>> [/quote]
>>
>>
Hi Mike,
* Mike Frysinger wrote on Thu, Jun 23, 2011 at 02:08:50AM CEST:
> http://sources.redhat.com/automake/automake.html#Extending
> [quote]
> Note that Automake does not make any distinction between rules with
> commands and rules that only specify depende
ugly limitation in automake itself. FTFM:
http://sources.redhat.com/automake/automake.html#Extending
[quote]
Note that Automake does not make any distinction between rules with
commands and rules that only specify dependencies. So it is not possible
to appen
Hello Daniel,
* Daniel Neuberger wrote on Wed, Apr 20, 2011 at 03:56:15PM CEST:
> Is there any way to make a dependent library implicitly use any
> compiler flags used by a library on which it depends?
Not automatically. libtool has 'inherited_linker_flags', but it is not
appropriate for your us
Is there any way to make a dependent library implicitly use any
compiler flags used by a library on which it depends? I'm running
into two problems that this would solve.
The first is illustrated by these Makefile.amS:
# libfoo
AM_CPPFLAGS = -I/some/include_path
lib_LTLIBRARIES = libfoo.la
libf
Is there any way to make a dependent library implicitly use any
compiler flags used by a library on which it depends? I'm running
into two problems that this would solve.
The first is illustrated by these Makefile.amS:
# libfoo
AM_CPPFLAGS = -I/some/include_path
lib_LTLIBRARIES = libfoo.la
libfo
btool
> > manual (10.3 Linking with dlopened modules, http://xrl.us/bjk9e5).
> > In that section, the manual recommends to use a weak library interface.
> >
> > However, the example given in the manual does not work because
> > the generated makefile lacks dep
rl.us/bjk9e5).
> In that section, the manual recommends to use a weak library interface.
>
> However, the example given in the manual does not work because
> the generated makefile lacks dependencies from libloader.la to
> libinterface.la's objects.
Indeed. The reference to t
rface.
However, the example given in the manual does not work because
the generated makefile lacks dependencies from libloader.la to
libinterface.la's objects. Here's a simplified and complete
version of the example in the libtool manual:
% cat >Makefile.am <<'EOF&#
hing
> >> yourself, or you omit it, and automake does a good job. But what about
> >> the case where you want automake to do its automatic dependencies, and
> >> then you add one more file? It seems like it would be nice to support
> >> foo_DEPENDENCIES
Hi Ralf,
In the end, this is where I wound up:
1. In configure.ac, ensure that there is some compilation language
a la AC_PROG_CC that enables the ``if AMDEP'' machinery
(i.e. AM_SET_DEPDIR gets invoked).
2. in Makefile.ac you have something like this:
> if AMDEP
> DEP_ARG = -M
Hi Wesley,
* Wesley Smith wrote on Tue, Jun 29, 2010 at 02:52:38PM CEST:
> I'm looking for some sample code on how to best check for an optional
> dependencies (like gstreamer or some other lib) and set a compilation
> flag like -DMYLIB_HAVE_GSTREAMER.
>
> I'm not e
I'm looking for some sample code on how to best check for an optional
dependencies (like gstreamer or some other lib) and set a compilation
flag like -DMYLIB_HAVE_GSTREAMER.
I'm not exactly which one of these functions or how to use them to do
this, so any pointers to a sample is much a
baz.F90
>
> However, bar.F90 depends on several other Fortran files (x.F90, y.F90,
> z.F90).
I take it that you mean that bar.F90 includes x.F90 etc., which in turn
means that bar.o depends on x.F90 etc.
> I would like to set up Automake to rebuild bar.o if the source of
> one of these
;
> foo_a_SOURCES = bar.F90 baz.F90
>
> However, bar.F90 depends on several other Fortran files (x.F90, y.F90,
> z.F90). I would like to set up Automake to rebuild bar.o if the source of
> one of these dependencies change.
>
> I've been reading the GNU manuals for automake/aut
Greetings,
I have a Makefile.am file right now that looks like this:
lib_LIBRARIES = foo.a
foo_a_SOURCES = bar.F90 baz.F90
However, bar.F90 depends on several other Fortran files (x.F90, y.F90,
z.F90). I would like to set up Automake to rebuild bar.o if the source of
one of these dependencies
On Mon, May 17, 2010 at 8:02 PM, Ralf Wildenhues wrote:
> adding of another variable to the default list of
> foo_DEPENDENCIES. I guess. Suggestions for naming such a variable?
foo_EXTRA_DEPS?
oki,
Steffen
gt; the case where you want automake to do its automatic dependencies, and
>> then you add one more file? It seems like it would be nice to support
>> foo_DEPENDENCIES += other_file, without requiring that foo_DEPENDENCIES=
>> previously occur in the file.
>
> Yes, such a
Hi Eric,
* Eric Blake wrote on Sat, May 15, 2010 at 01:41:08AM CEST:
> Right now, either you use foo_DEPENDENCIES and have to list everything
> yourself, or you omit it, and automake does a good job. But what about
> the case where you want automake to do its automatic dependencies, a
I just caused a build regression in libvirt because of my
misunderstanding about dependencies.
Right now, either you use foo_DEPENDENCIES and have to list everything
yourself, or you omit it, and automake does a good job. But what about
the case where you want automake to do its automatic
eck RECHECK_LOGS='. My question is how it is determined
> which tests are run in this case.
>
> It seems like if `foo' is newer than `foo.log', foo will be re-run
> but is that the only dependency? I would like to fine tune these
> dependencies. For instance, I have a
are run in this case.
It seems like if `foo' is newer than `foo.log', foo will be re-run but
is that the only dependency? I would like to fine tune these
dependencies. For instance, I have a test `yat_m4_test.sh' which uses
$(top_srcdir)/m4/yat.m4 and I want `yat_m4_test.sh' t
ow do I workaround it?
> > >
> > > Build the *_DEPENDENCIES variable yourself. You have to take care of
> > > all of its entries if you do so, it overwrites, not appends to, any
> > > automake-computed library dependencies.
> >
> > Would it be terribly bad
-lm and as I read your stmt above it
> should barf on -lm. Can GNU make handle this?
Seems like it. It's not portable to other makes though.
> > > How do I workaround it?
> >
> > Build the *_DEPENDENCIES variable yourself. You have to take care of
> > all of it
s -lm and as I read your stmt above it
should barf on -lm. Can GNU make handle this?
>
> > How do I workaround it?
>
> Build the *_DEPENDENCIES variable yourself. You have to take care of
> all of its entries if you do so, it overwrites, not appends to, any
> automake-com
as prerequisites
somewhere.
> How do I workaround it?
Build the *_DEPENDENCIES variable yourself. You have to take care of
all of its entries if you do so, it overwrites, not appends to, any
automake-computed library dependencies.
Cheers,
Ralf
I got this rule in Makfile.am:
ldadds_false = $(ldadds_cuappl)
ldadds_true = $(ldadds_culess)
common_LDADD += $(ldad...@cu_less@)
@CU_LESS@ is either true or false.
$(ldad...@cu_less@) is omitted in am__DEPENDENCIES_1 so
if any lib mentioned in ldadds_cuappl or ldadds_culess changes
no rebui
GeneralBase.def
>
> .mod.o:
> $(M2C) -c $(M2CFLAGS) $<
>
> MAINTAINERCLEANFILES = *~
>
> It runs fine. Like it would with C sources. The problem is, that defs
> aren't headers. They aren't included in the sources. If I change a
> definition file, the
the sources. If I change a
definition file, the change isn't recognized by make. Is there a way to
set the definitions as dependencies to sklib.a?
I have these extra dependencies:
SKTime.mod : SKGeneral.def TimeBase.def
SKVideo.mod : SKGeneral.def VideoBase.def
SKGeneral.mod : GeneralBase.def
Thanks.
Michiel Soede wrote:
- non-recursive make, is that the same as just making one big make
file that will always build
everything? So I would loose the ability to build (for example) only
one application, or library?
You can always issue `make foo' if you wanna build `foo' only.
- isn't there
: "John Calcote"
Sent: Tuesday, August 04, 2009 6:54 PM
To: "Michiel Soede"
Cc:
Subject: Re: library dependencies SUBDIR problem automake
Hi Michiel,
On 8/4/2009 10:01 AM, Michiel Soede wrote:
Hi,
I have a problem with dependencies to libraries in my build structure.the
dire
Hi Michiel,
On 8/4/2009 10:01 AM, Michiel Soede wrote:
Hi,
I have a problem with dependencies to libraries in my build structure.the
directory structure in my project is as follows (roughly):
configure.acmakefile.amapps/ makefile.am app1/
main.cc
Hi,
I have a problem with dependencies to libraries in my build structure.the
directory structure in my project is as follows (roughly):
configure.acmakefile.amapps/ makefile.am app1/
main.cc makefile.am comps/ makefile.am
Hi Akim,
* Akim Demaille wrote on Tue, Jun 23, 2009 at 11:52:43AM CEST:
> I might have missed the information, but I believe there are no
> instruction about handling the dependencies bw libraries are install
> time (they all live in the same Makefile.am, and I do not want to
> brea
Hi all,
I might have missed the information, but I believe there are no
instruction about handling the dependencies bw libraries are install
time (they all live in the same Makefile.am, and I do not want to
break it). I have libfoo that depends on libbar, and both are
installed in
Hello John,
thanks for the report.
* John Darrington wrote on Fri, May 01, 2009 at 01:58:30AM CEST:
> Sometimes an info file actually depends on more than one .texi
> file. For instance, in GNU Hello, hello.texi includes the file
> gpl.texi. You can tell Automake about these dep
The automake manual says:
Sometimes an info file actually depends on more than one .texi
file. For instance, in GNU Hello, hello.texi includes the file
gpl.texi. You can tell Automake about these dependencies using the
texi_TEXINFOS variable. Here is how GNU Hello does it:
info_TEXINFOS
Hello Peter,
sorry for the delay.
* Peter Breitenlohner wrote on Wed, Mar 18, 2009 at 10:35:51AM CET:
> Let me be somewhat more explicit and give you an (idealized) Makefile.am
> (fragment):
>
> if COND
> bin_PROGRAMS = prog
> endif COND
>
> prog_SOURCES = foo.c foo.h
> nodist_prog_SOURCES = bar.
t
> test_SOURCES=a.cpp b.cpp
> test_META=a.hpp b.hpp
> test_SOURCES+=$(test_META)
> test_LDADD = $(test_META:%.hpp=%_moc.$(OBJEXT))
>
> %_moc.cpp : %.hpp
> $(QT_MOC) -o $@ $<
> _EOF
>
> This all works fine for building the project, but it doesn't t
Never mind. Sometimes it is bad to work late at night. I had convinced
myself the following did not work.
For the record, here's the fixed makefile
On Tue, 31 Mar 2009, dherr...@ll.mit.edu wrote:
I'm using Qt 4's moc to generate source files in an autotools project.
The pattern looks somet
.hpp=%_moc.$(OBJEXT))
%_moc.cpp : %.hpp
$(QT_MOC) -o $@ $<
_EOF
This all works fine for building the project, but it doesn't track
dependencies for the moc source files properly. The dependencies are
getting dropped in $(DEPDIR)/*_moc.Po, but the Makefile doesn't have a
On Tue, 17 Mar 2009, Ralf Wildenhues wrote:
Hello Bob and Ralf,
thanks for your replies, unfortunately they gave me no new insight
Well, do you distribute any files that depend on these built files?
If you stick to distributing all files which are prerequisites to
distributed files, then there
r a stamp
file in BUILT_SOURCES I guess.
> What is the best way to teach this kind of dependencies to Automake,
> avoiding unnecessary tasks, not interfering with Automake's automatic
> dependency tracking,
I don't think any of the above would interfere with dependency tr
: a tool generates a C file plus header from one source,
and another C file plus header from another source. Each of these C files
includes both headers, therefore the C files can not be compiled before both
headers have been created.
What is the best way to teach this kind of dependencies to
On Tue, Mar 3, 2009 at 1:32 PM, Ralf Wildenhues wrote:
> * Allan Caffee wrote on Tue, Mar 03, 2009 at 07:14:51PM CET:
>> I just wanted to follow up on this. I decided not to post the
>> series to the list.
>
> Why not? If it is larger than a couple dozen KB, then you can still use
> the -patches
* Allan Caffee wrote on Tue, Mar 03, 2009 at 07:14:51PM CET:
> On Fri, Feb 13, 2009 at 10:43 AM, Allan Caffee wrote:
> > Ideally the macro archive would provide a way to
> > produce these rules in a way that they would be available for Automake to
> > work
> > its magic. I'm working on a patch s
On Fri, Feb 13, 2009 at 10:43 AM, Allan Caffee wrote:
> Ideally the macro archive would provide a way to
> produce these rules in a way that they would be available for Automake to work
> its magic. I'm working on a patch series that would allow macro developers
> provide an Automake include-able
, too.
> The respective statement looks like this:
> @am__include@ @am__qu...@file@am__quote@
Yes that's how Automake manages to provide dependencies as a side effect of
compilation, right? I remember abusing this at one point to get the Autotools
to make use of some automatic dependencies generated by a script of mine. :)
Allan
Hello Allan,
* Allan Caffee wrote on Wed, Feb 04, 2009 at 12:38:01AM CET:
> First of all I wasn't really sure where to start this thread so if
> this isn't the appropriate place I apologize.
This is very well appropriate here.
> I've noticed that a handful of the packages in the Autoconf archive
First of all I wasn't really sure where to start this thread so if this isn't
the appropriate place I apologize.
I've noticed that a handful of the packages in the Autoconf archives use the
macros AX_ADD_AM_MACRO and AX_ADD_RECURSIVE_AM_MACRO. These macros add targets
and variable assignments to
Hello, Brian
Thank you for your hint on `make' from CVS. It really works.
On 7/2/08, Brian Dessent <[EMAIL PROTECTED]> wrote:
> I never said that fopen("c:/foo") wouldn't work, but it's because the
> Cygwin APIs simply pass-thru arguments to the underlying Win32 APIs that
> don't look like POSI
[EMAIL PROTECTED] wrote:
> Some strictly positive amount of interoperability exists.
> When I gcc c:/cygwin/home/15-6-1/tmp/m/sample.c, it
> produced a.exe (gcc 'c:\cygwin\home\15-6-1\tmp\m\sample.c', too).
>
> sample.c contained
> #include
> int
> main(void)
> {FILE*f=fopen("c:\\sample.txt","w")
On 7/1/08, Brian Dessent <[EMAIL PROTECTED]> wrote:
>The essential point is that using native Win32 tools with Cygwin causes
>problems. This is because Cygwin is designed to closely emulate a POSIX
>environment, and the tools aren't equipped to deal with Win32 paths with
>drive letters. This is n
t has it's own based on msys.
It's gcc honestly tells where it's headers have been installed.
I checked the WinAVR make, it can deal with such dependencies.
Unfortunately, it does not work on cygwin.
Probably the best is to build WinAVR tools from scratch on cygwin.
>Well, first yo
1 - 100 of 312 matches
Mail list logo
