tly how to do
this, and it MIGHT be useful to augment PKG_CHECK_MODULES.
Does anybody have some good/complete example cases for this?
What's a good way to evolve this?
--
Harlan Stenn
http://networktimefoundation.org - be a member!
For example, the solution below does not work for "distclean".
H
--
Harlan Stenn writes:
> Gavin Smith writes:
> > On 11 July 2015 at 06:38, Harlan Stenn wrote:
> > > I'm thinking I want to run a hook before the distdir target is run.
> > >
> >
Gavin Smith writes:
> On 11 July 2015 at 06:38, Harlan Stenn wrote:
> > I'm thinking I want to run a hook before the distdir target is run.
> >
> > What's a good way to do that?
> >
> > The reason for this is ...
>
> Could you do some trick w
Peter Johansson writes:
>
>
> On 06/24/2015 10:20 PM, Harlan Stenn wrote:
> > So I notice that in automake-1.15 the distcheck stuff is now begin built
> > in _build/sub/. I am generating some files for our test framework that
> > want to access stuff in srcdir.
>
ood answer is to have a pre-dist hook of some sort, so if
somebody wants to run 'dist' I can make sure that the needed
sub-packages have been built.
--
Harlan Stenn
http://networktimefoundation.org - be a member!
.
This doesn't seem to be documented at
http://www.gnu.org/software/automake/manual/automake.html .
How do I "make it go" again with 1.15?
--
Harlan Stenn
http://networktimefoundation.org - be a member!
You might also want to look at modules.sourceforge.net .
At one time there was a project that was a package manager that expected
to install each package using the "modules" framework, but that was
years aog and it never got off the ground.
If I had the time I'd be working on that.
H
Eric Blake writes:
> On 04/13/2015 04:24 PM, Arthur Schwarz wrote:
> >
> > I am trying to echo:
> >echo 'exit $status' >> file
> >
> > from the Makefile generated by Makefile.am. What I get is:
> >echo 'exit $status' >> file
> >
> > in the Makefile, which is correct, but in execution (ma
"Arthur Schwarz" writes:
>
> I am trying to echo:
>echo 'exit $status' >> file
echo "exit $status" >> file
H
--
> from the Makefile generated by Makefile.am. What I get is:
>echo 'exit $status' >> file
>
> in the Makefile, which is correct, but in execution (make check) I get
>exit
Hi Peter,
Peter Johansson writes:
> On 03/08/2015 07:46 PM, Harlan Stenn wrote:
> > The problem I'm seeing (with at least automake-1.12.1 and automake-1.15)
> > is that the .deps directories are not being created along the subdir
> > path, so the build is failing.
&
Bob Friesenhahn writes:
> On Sun, 8 Mar 2015, Harlan Stenn wrote:
> >
> >> Due to the availability of Automake include files, hardly any text
> >> need appear in a top-level Makefile.am, although the full content of
> >> Makefile.in would appear at that location
ed
> Content-ID:
> Content-Transfer-Encoding: quoted-printable
> X-MIME-Autoconverted: from 8bit to quoted-printable by blade.simplesystems.or
> g id t28JNYFB013474
>
> On Sun, 8 Mar 2015, Harlan Stenn wrote:
>
> >
> > 'make dist' and 'make dis
Bert Wesarg writes:
> I think we must distinguish between a toplevel-Makefile.am and
> 'sub'-Makefile.am. 'sub' may be a recusive Makefile.am in the same
> 'configure.ac' project, or in a sub-'configure.ac' project. And
> referencing source files outside of a sub-Makefile.am's tree but
> inside a t
Bob Friesenhahn writes:
> I checked the current Automake manual and am not able to find any text
> which says that a subdirectory needs to be a subdirectory of where the
> Makefile resides. What is a subdirectory anyway? The generated
> Makefile would include per-source-file target specificati
Bob Friesenhahn writes:
> On Sun, 8 Mar 2015, Harlan Stenn wrote:
> >
> > The problem I'm seeing (with at least automake-1.12.1 and automake-1.15)
> > is that the .deps directories are not being created along the subdir
> > path, so the build is failing.
>
Harlan Stenn writes:
> I've got an "old style" build tree and I'm trying to convert it to use
> subdir-oobjects.
>
> I've got a good number of subdirs in this project, and some of these
> subdirs contain source files but no Makefile.am (or derivatitive
I get this behavior with both FreeBSD's make and with gmake. I am using
VPATH.
What am I missing?
If the answer is "Wait until autoconf-2.70 and automake-2.0" that's an
OK answer. I'm just trying to prepare for this a bit earlier.
--
Harlan Stenn
http://networktimefoundation.org - be a member!
Stefano Lattarini writes:
> On 01/02/2015 02:16 AM, Harlan Stenn wrote:
> > Excellent timing, thanks!
> >
> > Now that ntp-4.2.8 is settling down, I'm looking to update our
> > Makefile.am's to use subdir-objects, and it's not being fun.
>
>
Excellent timing, thanks!
Now that ntp-4.2.8 is settling down, I'm looking to update our
Makefile.am's to use subdir-objects, and it's not being fun.
I may wait until 1.15 is released to continue this effort.
H
David Beer writes:
> I'm curious though - am I really the only person having this issue?
> How are people using unit tests with the new version of automake? It
> would seem that these changes make it very difficult for anyone who
> has unit tests in their project.
I can't speak to the unit test is
Peter Johansson writes:
> On 02/27/2014 11:05 AM, Harlan Stenn wrote:
> > Yes, understood. And the problem is that am__configure_deps includes
> > am__aclocal_m4_deps, which includes aclocal.m4.
>
> Inaccurate. am__configure_deps includes aclocal,m4 via var
Hi Peter,
Peter Johansson writes:
> On 02/27/2014 04:47 AM, Harlan Stenn wrote:
>> So while the filestamps are technically correct, the generated
>> Makefile *will* see that version.m4 is newer than config.h.in and
>> regenerate it via Makefile dependencies.
>>
>>
Adding automake to the list, as with the information below this is now
looking like an automake issue.
I rolled another release and here's what I see:
harlan@hms-mbp11% ls -ltrT config.h.in sntp/config.h.in aclocal.m4
sntp/aclocal.m4 sntp/m4/version.m4
-rw-rw-r-- 1 harlan wheel 40 Feb 23 1
For NTP, we have a kinda hard to describe but easy to read mechanism.
For development versions (odd-number minor releases) each new "issue"
gets a bumped "point number" (major.minor.point). If that issue is a
release candidate it gets a "-RC" suffix.
For stable versions (even-number minor releas
e-installation directories in addition to the expected
installation directories because those might open holes with the
installed scripts.
There is also the separate issue of people changing the PMDIR location
on the "make install" invocation, but I'm OK solving this problem later.
Sugg
Stefano Lattarini writes:
> On 07/22/2013 04:18 AM, Harlan Stenn wrote:
> > For reasons I have no forgotten, our software requires automake-1.10 or
> > later to build.
> >
> > I do our builds with 1.11.1 right now, and I have the vague memory that
> > there w
let other folks
know as well so they'd know why we made our choice.
Anybody have some information for me?
--
Harlan Stenn
http://networktimefoundation.org - be a member!
Stefano Lattarini writes:
> ...
> which shows the issue has nothing to do with Automake. In fact, the above
> works if I use Texinfo 5.x instead of Texinfo 4.13!
I've been bitten by this several times before, with sufficient delays in
between these occurrences that it usually takes me a bit of di
Bob Rossi writes:
> Autotools is a great build system. However, after configuring it to
> place as many files as possible in a subdirectory, it still takes up
> 87.5% of my projects root directory.
>
> aclocal.m4
> autom4te.cache
> build
> configure
> configure.ac
> Makefil
Sam Varshavchik writes:
> Harlan Stenn writes:
> > The problem I've had is that the info above does a great job of saying
> > "recursive Make can be a problem" but I haven't found anything to help
> > me make a useful non-recursive Make system.
>
>
Stefano Lattarini writes:
> My suggestion: if files in different subdirectories are actually
> dependent on each other (that is, the subdirectories are not
> really independent "modules" that can be built independently and
> oblivious to each other), re-organize your build system to stop
> using ma
List the .c and .h files in FOO_SOURCES.
H
> I want to build a target like this:
>
> $ cat Makefile.am
> bin_PROGRAMS = prog
> prog_SOURCES = file.f ../lib/lib.o
Try prog_LDADD, and see
http://www.gnu.org/software/automake/manual/automake.html#Program-and-Library-Variables
H
Yes, and you also don't need to worry about DIST if you are using a .in
file and letting config.status (via configure) do the substituting.
H
Bottom line is that I have:
foo/scriptname.in: the script source
foo/Makefile.am:
bin_SCRIPTS = scriptname
configure.ac:
AC_CONFIG_FILE([foo/scriptname], [chmod +x foo/scriptname])
H
Sorry I don't have time to do better than point you at:
http://www.gnu.org/software/automake/manual/automake.html#Scripts
and the way we use for NTP is a bit nastier, as we support installing
programs and scripts into configure-specified directories based on the
OS (for legacy reasons). But I a
I wrote:
> > Harlan Stenn writes:
> > > What's the problem with bin_SCRIPTS?
> >
> > Hmm, I didn't know about it, but ... reading the documentation,
> > "bin_SCRIPTS" doesn't actually seem to do much of anything -- you
> > stil
> Harlan Stenn writes:
> > What's the problem with bin_SCRIPTS?
>
> Hmm, I didn't know about it, but ... reading the documentation,
> "bin_SCRIPTS" doesn't actually seem to do much of anything -- you
> still have to add your own rules to han
What's the problem with bin_SCRIPTS?
H
Warren wrote:
> On 11/22/2011 6:02 PM, Harlan Stenn wrote:
> > The BSDs have their good reasons to want to avoid GPL'd code, especially
> > GPL3.
>
> Besides, why should BSD purity get to hold back the Autotools?
So GNU/Linux purity is fine but BSD purity is not?
>
Warren wrote:
> > So far, automake has not been using gmake, so why should it
> > now start doing so?
>
> Because gmake is all but ubiquitous, and has been so for a decade.
>
> The only exception I can think of is the BSDs, which still stubbornly
> stick to BSD make, apparently for political rea
Ralf wrote:
> If automake so far has been able to achieve its job, by not using
> gmake proprietary constructs in its Makefile.ins, then there should
> not be any need for automake to _now_ start using gmake-constructs in
> Makefile.ins.
I agree, there is probably no *need*.
> Or simpler: So far
I probably still do the lion's share of updates to the Makefile.am's in
NTP, at least for nontrivial changes. But I'm not sure that matters for
this discussion. (And Dave Hart has done a few of the tricky ones,
too.)
NTP started using autoconf as its "detection needs" are ... nontrivial,
and sta
Bruno wrote:
> Cross-compiling means that the generated executable can not be run on
> the build machine.
Is that different from executables generated on the build machine cannot
be run on the host machine?
H
Stefano wrote:
> Partecipants to the Google Summer of Code are required to stop working
> on their projects at August 22 19:00 UTC, ...
I don't believe that is correct. Students are free to keep working on
their projects for as long as they want - it's just that for purposes of
the GSoC student
Hi Stefano,
Thanks for the suggestion - it was pretty much along the lines I thought
I'd have to go before Ralf posted.
H
Ralf,
That works just fine - thanks!
H
d -f m4/mansec.sed $(srcdir)sntp.$(MANTAGFMT).in > sntp.$(SNTP_MS)
but the 'install-man' target remains "empty".
I'm really hoping I don't have to enumerate the choices and use automake
conditionals to choose the verisons I want...
--
Harlan Stenn
http://ntpforum.isc.org - be a member!
Pippijn wrote:
> On Sat, Mar 19, 2011 at 10:38:39AM +0100, Pippijn van Steenhoven wrote:
> > On Fri, Mar 18, 2011 at 05:26:58PM -0700, Harlan Stenn wrote:
> > > If there was a student interested in showing how "easy" it was to use
> > > automake to do non-recu
Pippijn wrote:
> On Fri, Mar 18, 2011 at 05:26:58PM -0700, Harlan Stenn wrote:
> > If there was a student interested in showing how "easy" it was to use
> > automake to do non-recursive Makefiles for a project, I'd be willing to
> > co-mentor and work with
Hi Ralf,
Ralf wrote:
> * Harlan Stenn wrote on Sat, Mar 19, 2011 at 01:26:58AM CET:
> > If there was a student interested in showing how "easy" it was to use
> > automake to do non-recursive Makefiles for a project, I'd be willing to
> > co-mentor and work with
If there was a student interested in showing how "easy" it was to use
automake to do non-recursive Makefiles for a project, I'd be willing to
co-mentor and work with them to convert NTP to that sort of operation.
--
Harlan Stenn
http://ntpforum.isc.org - be a member!
I'm curious/interested about the TAP effort, as it might tie in nicely
with some stuff we're working on for NTP:
https://support.ntp.org/bin/view/Dev/GSoCProjectIdeas#Unit_tests
Thanks a bunch Stefano,
As long as the "mechanism" works (ie, I can set an ACLOCAL_PATH to a set
of directories and the right thing happens) I can solve my problem by
applying a local patch, and when the dust settles and a production
solution is in place then newer releases of automake will no lon
Ralf mentioned there, which are pretty much the same reasons I
mentioned in June of 2002) has again resurfaced.
I'm not seeing any environment variable to do this in 1.11.1 - am I
missing something, or is there a new way I should be handling this?
--
Harlan Stenn
http://ntpforum.isc.org - be a member!
I would suggest that proposals offer useful hints and links to
information and concepts, but I would recommend against spelling the
proposals out in significant detail. The reason for this is that
sometimes students will do an excellent job of either regurgitating or
paraphrasing a proposal. It t
Eric wrote:
> As I said, we do use NTP to keep our machines in synchronization, every
> hour. ...
If you are doing something other than running ntpd as a daemon, you are
likely not keeping your clocks sync's well enough to keep NFS timestamps
happy.
H
You could look at the configure.ac in ntp-dev (or any recent
ntp-stable), say:
http://ntp.bkbits.net:8080/ntp-dev/configure.ac?REV=4b6a0c4clgted0re5ogPZQx0QgLLPw
and find the hunk of code starting with:
AC_MSG_CHECKING([for openssl include directory])
and decide for yourself if there is a be
Richard,
Why are all the header files from Projects/subA/ being enumerated in the
compile line? I think that's the problem.
H
Oh, you are probably using NFS for this - ntpd will need to be running
on the NFS server and your local box.
H
Hi Abdolah,
ntp is probably already installed on your computer.
You will need to configure it and start it.
You can learn more at:
http://support.ntp.org/bin/view/Support/ConfiguringNTP
http://support.ntp.org/Support/StartingNTP4
We would love to find ways to make the information at those l
Dave Hart wrote:
> You're running up against something else. AM_CONDITIONAL goes back
> some time, and has worked splendidly for the NTP reference
> implementation built using Automake 1.10.
and even automake 1.9, and probably earlier versions as well.
H
uss this issue (my preference would be a wiki page, as I hate
sniffing thru email discussions) and make changes after we have a wide
enough and deep enough understanding of the issues.
--
Harlan Stenn
http://ntpforum.isc.org - be a member!
I wrote:
> In what version of automake did abs_builddir first appear?
>
> I know it was post-1.9.6...
Looks like it first appeared in 1.10.
H
In what version of automake did abs_builddir first appear?
I know it was post-1.9.6...
--
Harlan Stenn
http://ntpforum.isc.org - be a member!
William,
I did a lot of what you are talking about when I was there - do you have
access to any of the ATC stuff?
H
Umut,
Check out the BUILT_SOURCES variable.
H
Ralf wrote:
> What I meant was this:
> ./configure --prefix=/usr/local
> make
> make install exec_prefix=
>
> with Automake 1.10.2, most likely ends up with an error at installation
> time, or with "install" overwriting files in the build tree or so. And
> this:
>
> ./configure --prefix=
Russ wrote:
> Ralf Wildenhues writes:
> > [1] I'm asking because Automake 1.11 will reliably not install files if
> > their respective installation directory is empty. This is not yet
> > functional in Automake 1.10.2. The test for emptiness in 1.11 will not
> > consider $(DESTDIR) of course, on
* Andreas wrote on Sun, Jan 25, 2009 at 06:42:52PM CET:
> fileA.c \
> fileB.c \
> fileC.c
> [...]
I do it this way:
NULL=
...
FOO= \
fileA.c\
fileB.c\
$(NULL)
BAR= \
fileC.c\
fileD.c\
$(NULL)
Mostly I do this so it is easy for me to "sor
> Hello!
> I have a question about GNU automake.
> I have a helper script in tests subdirectory of my project.
> This script is used ONLY for tests (make check).
> So, it should be distributed.
>
> I added the following lines
> dist_bin_SCRIPTS = fds_by_process.sh
> check_SCRIPTS = fds_by_process.
> On Mon, Jun 30, 2008 at 4:39 PM, Harlan Stenn <[EMAIL PROTECTED]> wrote:
> > sysconf_SCRIPTS
> >
>
> Hi,
>
> If I do that, 'automake' will fail and report:
>
> Makefile.am:10: `sysconfdir' is not a legitimate directory for `SCRIPTS&#
sysconf_SCRIPTS
H
--
> Hi,
>
> I use "sysconf_DATA= etc/net.up etc/net.down" in my Makefile.am
> and expect that when I run 'make install' then those shell scripts
> (net.up, net.down) can be installed in PREFIX/etc . It really work,
> just except that these scripts are not chmod to executab
Bob Friesenhahn wrote:
> Setting up a non-recursive build project with Automake would not be
> such a chore if Automake knew how to ingest per-subdirectory Makefiles
> into the overall build, adding any necessary path information. The
> biggest chore related to setting up a non-recursive build
You typo'd.
I wrote BUILT_SOURCES= ...
Check out the docs.
H
--
> On Fri, Mar 21, 2008 at 3:57 PM, Harlan Stenn <[EMAIL PROTECTED]> wrote:
>
> > > I like to include my subversion version number in my rpm spec file so I
> > can
> > > keep track of the
You may also want:
noinst_DATA = poll.spec
H
> > I like to include my subversion version number in my rpm spec file so I can
> > keep track of the source used to generate the binary. I've been manually
> > changing it but since I forget to sometimes, I'd like for make to generate
> > the spec fi
> I like to include my subversion version number in my rpm spec file so I can
> keep track of the source used to generate the binary. I've been manually
> changing it but since I forget to sometimes, I'd like for make to generate
> the spec file for me. I wrote a small perl program that reads a t
> Does automake support building shared libraries without using libtool?
It's possible.
The reason folks use libtool is that libtool knows about how to make
shared libraries on *many* different systems, and it addresses the
shared library version issues.
For people who want to write code and let
Erik wrote:
> Harlan Stenn wrote:
>
> > You can use: ../common/mySleep.c in your foo_SOURCES list.
>
> If the sources are in /home/user/src and you go to /home/usr/build
> and do "../src/configure" the above will be completely wrong.
>
> The correct way to
John,
> Bob, server/Makefile's VPATH only contains the expansion of
> @top_srcdir@/server, which in this case is ../../server. This means
> that make won't be able to find any sources listed that exist in
> directories other than ../../server. So I think I HAVE to use
> $(top_srcdir)/common/mySlee
Nick,
> I wrote a Makefile.am which includes a source file called b.C, which is
> a C-source and not a C++-source. In configure.ac I have AC_PROG_CC. When
> I run automake I get the error message:
>
> Makefile.am: C++ source seen but `CXX' is undefined
> Makefile.am: The usual way to define `CX
Bernd wrote:
> On Dec 18, 2007 7:41 AM, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> > At the FSF lawyers, trying to rewrite the license exceptions that are
> > present in autotools, so that the rewording is suitable for GPLv3+.
>
> If there are projects out there that urgently need a new automake
And of course, NFS file attribute caching can make detecting clock skew
a whole lot more interesting.
H
Bob Friesenhahn wrote:
> On Thu, 22 Nov 2007, Harlan Stenn wrote:
> > I *think* I'd be happy with 'clock skew in the build directory'.
>
> You mean like
>
>CPU -- NFS (Sources + Objects)
This is one case I know I care about.
> or
>
&
Bob Friesenhahn wrote:
> On Wed, 21 Nov 2007, Harlan Stenn wrote:
> >
> > A variety of problems can crop up if one is "doing things" in an
> > NFS-mounted filesystem and there is clock skew between the local machine
> > (NFS client box) and the machine t
I have not put enough thought into the following.
A variety of problems can crop up if one is "doing things" in an
NFS-mounted filesystem and there is clock skew between the local machine
(NFS client box) and the machine that hosts the actual filesystem (NFS
server box).
I am thinking there may
Perhaps I am confused. And I don't have a cross-compile build anywhere
handy.
I thought that the cross-compile setup built and linked a test
executable and scanned for known filenames. It does not try and run the
generated file.
This should work on a cross-compile build just the way it is.
H
Hey folks,
I found the code I was using to detect broken vpath support.
The culprits seemed to be:
*-*-irix6.2 (and later. ie, *-*-irix6.1* was OK)
solaris2.5.1
*-*-unicosmp
And just to reaffirm, I agree with Ralf that the particular issue has to
do with the way FreeBSD avoids (as I understa
Paul,
Thanks for your response.
> On Tue, 2007-11-06 at 19:46 +0000, Harlan Stenn wrote:
> > I'm getting bitten by the VPATH-handling differences between FreeBSD's
> > make and gmake.
>
> The automake manual says (somewhere) that the only version of make that
I'm getting bitten by the VPATH-handling differences between FreeBSD's
make and gmake.
I have a .y file and I currently distribute the bison-generated .[ch]
files in the distribution.
On a stock FreeBSD machine (at least) when doing a build outside of the
source tree, FreeBSD's make doesn't see t
Benoit wrote:
> I usually do this in my configure.ac:
>
> AC_PROG_CXX
> # Speed GCC compilation up.
> if test "$GXX" = yes; then
>CXXFLAGS="$CXXFLAGS -pipe"
> fi
I use case statements wherever possible instead of 'test'.
While 'case' is a shell builtin, 'test' may not be. If there are a
bun
Why worry about which library files should be executable and which ones
are not?
Would it be easier to use:
foodir=/where/ever
foo_LIBRARIES = ...
and let the generated Makefile handle getting the permissions right?
H
Beniot wrote:
> OK look, here is how it goes AFAIK:
> - You want to set project-wide flags, use AM_CFLAGS
> - Your user wants to set project-wide flags, it does: ./configure
> CFLAGS=...
> - If your user didn't set project-wide flags, AM_PROG_CC may put
> some default flags in CFLAGS (tha
> Harlan Stenn wrote:
> > I'll say it again - I am not interested in a reminder, I am interested
> > in being efficient at maintaining software packages. This means
> > *shortening* the development cycle.
> Yes, this would seem to be the values set of automake. Shor
I really dislike this proposal as it stands.
While I'm fine with a position that says "for normal users, don't have
Makefile.in depend on Makefile.am", I *want* that rule as a package
developer and even as a release engineer.
I already have way too much stuff I have to remember to do, and adding
> Harlan Stenn wrote:
> > I really dislike this proposal as it stands.
> >
> > While I'm fine with a position that says "for normal users, don't have
> > Makefile.in depend on Makefile.am", I *want* that rule as a package
> > developer and even
'make distcheck' can also be your friend.
H
I've had similar problems with the NTP release.
I ended up using 'foreign' for that and other reasons.
I have also since decided to have 3 files in the top-level directory.
The NEWS file is now high-level release notes.
The ChangeLog file is now a human-edited list of short changes (one
liners
What about PATH issues and '.'? It may not be a problem, but the
thought leapt into my mind...
H
--
> Following these lines, it's nonsense to maintain some
> half-support for non-executable install-sh. If we don't want to
> support this use-case, ${SHELL} should be fully removed from
> every cal
Hi Ralf,
> > > Two ways to get out of this:
> > > - do not stick $(srcdir)/ in front of the prerequisites. For example,
> > > this should work portably (if you take care not to stick $(srcdir)/
> > > elsewhere before the *.in files):
> > >
> > > rpmbuildupdate: rpmbuildupdate.in
> > > perl
1 - 100 of 274 matches
Mail list logo
