pkg-conf and LD* variables

[Harlan Stenn]

pkg-conf offers the following ways to get "link flags":

 --libs All link flags
 --libs-only-L  The -L/-R stuff
 --libs-only-l  The -l stuff
 --static   Output ilbraries suitable for static linking

and then says the union of -only-L and -only-l may be smaller than the
output of -libs because the latter might include flags like -rdynamic.

We're already having to parse the output of pkg-config to try and
separate LDADD stuff from LDFLAGS stuff,  And this is before we start to
address static v. dynamic things.

This is because we really don't want -L stuff in LDADD, because we end
up with things like:

 No rule to make: -L /usr/local/lib

(or something).

The autoconf macro PKG_CHECK_MODULES hasn't been all that helpful to us.

What's a good way to deal with this?

One could say that pkg-conf could be doing a better job.  But even if it
does, this would still require the folks who write the .pc files to do a
better job of specifying their contents.

Until we can expect .pc files to have proper content, I suspect we're
going to need to have better smarts in autoconf/automake.

But this will also require some better info about exactly 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!

Re: pre-dist hook?

[Harlan Stenn]

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.
> > >
> > > What's a good way to do that?
> > >
> > > The reason for this is ...
> > 
> > Could you do some trick with EXTRA_DIST? You could have a file that
> > only exists when the nested packages are configured that has to be
> > distributed.
> 
> I have been playing with this for a while now and this what I am
> currently using.  I have a dependency on the distributed subdirectory in
> the build tree.  If it's there, great.  If it's not, I have a rule that
> will stop the 'make' (for at least gmake and pmake) telling the user that
> they need to --enable-local-libevent when running configure if they want
> to run any "dist" target.
> 
> I would not be surprised to discover there are still corner cases, but
> for now this solution seems to be OK.
> 
> Thanks!
> 
> H
> 

Re: pre-dist hook?

[Harlan Stenn]

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 with EXTRA_DIST? You could have a file that
> only exists when the nested packages are configured that has to be
> distributed.

I have been playing with this for a while now and this what I am
currently using.  I have a dependency on the distributed subdirectory in
the build tree.  If it's there, great.  If it's not, I have a rule that
will stop the 'make' (for at least gmake and pmake) telling the user that
they need to --enable-local-libevent when running configure if they want
to run any "dist" target.

I would not be surprised to discover there are still corner cases, but
for now this solution seems to be OK.

Thanks!

H

Re: _build/sub and distcheck

[Harlan Stenn]

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.
> >
> > I have these .in files using @srcdir@, but with the change from _build
> > to _build/sub this expansion is no longer working.
>
> @srcdir@ should expand to ../.. in _build/sub/Makefile, so it should 
> still work. What am I missing?

I'm not sure, but we found a way to make it work.  If it bites us again
I'll dig deeper.

H

pre-dist hook?

[Harlan Stenn]

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 that I'm packaging at least 2 nested packages in
my distribution.  We only want to configure these if we need them.  The
"problem" is that folks who don't need either/both of these packages
don't want to spend the time configuring them, but in that case they
cannot run "make dist" either.  To produce a distribution, one must
generally configure these sub-packages so the dist target(s) can see
these packages.

So I figure a good 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!

_build/sub and distcheck

[Harlan Stenn]

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.

I have these .in files using @srcdir@, but with the change from _build
to _build/sub this expansion is no longer working.

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!

Re: Multiple version installation

[Harlan Stenn]

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

Re: How do you echo a shell variable reference

[Harlan Stenn]

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 (make check) I get
> >exit tatus
> > 
> > in file. I have tried variations of $status to no avail. Any idea how I can
> > get the correct result in file?
> 
> The same as any other time you want a literal $ to be passed through to
> the shell when writing Makefile snippets: escape the $ with another $,
> so that 'make' won't try to treat it as an expansion of ${s} at make time:
> 
> foo:
>   echo 'exit $$status' >> file

Ah, I missed the type of expansion/quoting being desired.

H

Re: How do you echo a shell variable reference

[Harlan Stenn]

"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 tatus
> 
> in file. I have tried variations of $status to no avail. Any idea how I can
> get the correct result in file?
> 
> 
> Software entropy: maintenance
> 
> 
> 
> 

Re: converting to subdir-objects

[Harlan Stenn]

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.
> >
> > So if A/Makefile.am contains:
> >
> >   foo_SRCS = ... $(srcdir)/../foo/bar.c
> Hi Harlan,
> 
> I had the same issue and wouldn't care unless Automake 1.15 started to 
> warn about "source file in a subdirectory". In my case 'bar.o' is also 
> built from 'foo/Makefile' so I decided to skip using 'bar.c' as SOURCE 
> and instead link in 'foo/bar.o'.
> 
> http://dev.thep.lu.se/svndigest/changeset/1581

The problem is that in this case, A/Makefile is the *only* place that
bar.o is created and used.  There is no other location for me to link to
an object.

H

Re: converting to subdir-objects

[Harlan Stenn]

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 in the source package.
> >
> > I'll probably be doing that too, but at this point I'm looking at the
> > "include" solution more for a conversion to non-recursive Makefiles,
> > which I'm also not thrilled about because there are plenty of times I
> > want to go to a specific directory and run "make" and have it DTRT.
> 
> From your description, it seems that some target object files (the 
> ones arrived at via ../) may be built by multiple Makefiles because 
> these are deemed to be shared files.  This seems problematic.
> 
> When convenience libraries are used, usually just one Makefile is 
> responsible for building that convenience library and recursion is 
> used to enter the directory to build that library.  This assures 
> consistent build options but it also dramatically slows the build. 
> If the source files were fully enumerated (listed) by the Makefile for 
> the using application, then there could be simultaneous requests to 
> build the same object at once and the options provided during the 
> build might not be consistent.  If there is just a single Makefile for 
> the whole project then these issues disappear and the need (and 
> hopefully desire!) for evil convenience libraries also should 
> disappear.

The usual case is one where I'm building a single library from sources
in multiple places.

There are more rare cases where I'll be using a single file for multiple
builds, and each will likely have some different -D flags passed in.

Not sure about this last one.  I know there are some files where I
created a small .c file that sets up the needed options using #define's
and I don't think I've had to mess with any of these for maybe 10 years'
time, so my recollection is fuzzy.  There are other cases where I am
building different .o files from the same .c file with differend -D
options, but those are all in the same subdir.

> If you want to emulate old style per-directory builds, why not put a 
> tiny classic Makefile there which executes make on the master Makefile 
> and requests only the target(s) which may be built in that directory? 
> This will not eliminate other re-builds found necessary due to source 
> file changes (only for those necessary for current targets), but would 
> result in only the target(s) for that directory being built.  The 
> incremental build time would still be reduced.

I'm happy to look at that, and each of these Makefiles will need to be
generated by configure (config.status) because they need to be in the
build tree.  I figure that's a project to look at once I get
subdir-objects going.

> Turn convenience libraries into Makefile variables since Makefile 
> variables are vastly more efficient than clunky convenience libraries.

I'm happy to look at that, and it means I'd want a single place to
define these Makefile variables and then I'd have to update all the
places they're used.

If with subdir objects this means a single copy of these files will be
built and shared that seems great.

I'm not seeing value in converting to Makefile variables at this point.

The current convenience libraries take a bit longer.  But I think we
only have one of them.

If converting to subdir objects doesn't make things much slower and it
avoids warnings, that's enough for me.

If a way can be found to get a non-recursive solution implemented as
well where we still have the "build" options we want, so much the better.

> This is what I tremendously enjoy seeing (since September, 2004):
> 
> Whole project with nothing to do (no "Making all in dir" messages) ...
> % time make -s
> make -s  0.46s user 0.03s system 88% cpu 0.562 total
> % time make -s
> make -s  0.44s user 0.01s system 98% cpu 0.462 total
> 
> Specific target with nothing to do (still assured to be correct) ...
> % time make -s ./utilities/gm
> make -s ./utilities/gm  0.22s user 0.02s system 98% cpu 0.241 total
> % time make -s ./utilities/gm
> make -s ./utilities/gm  0.22s user 0.02s system 98% cpu 0.240 total
> 
> And there is the benefit that almost everything (except for linking) 
> can be built simultaneously, using all available CPU cores.

That is great, especially if this approach is no slower for builds folks
have to do on single-core slow boxes, too.

H

Re: converting to subdir-objects

[Harlan Stenn]

Bob Friesenhahn writes:
>   This message is in MIME format.  The first part should be readable text,
>   while the remaining parts are likely unreadable without MIME-aware tools.
> 
> ---559023410-713165029-1425842271=:4186
> Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-7; FORMAT=flowed
> 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 distcheck' have been working fine for a Very Long
> > Time in this project.
> >
> > In my attempt to get subdir-objects working NTP, I added
> > "subdir-objects" to the list of options in the AM_INIT_AUTOMAKE line in
> > its configure.ac file.  I figured I'd add that option, run autoreconf,
> > 'make', and see what happened.
> 
> I had the perhaps mistaken impression (due to the mention of "old=20
> style" build tree") that you are migrating to a non-recursive build.

Not yet, and again, while I'd love to find a way to convert to a
non-recursive build I really do like the ability to have a Makefile in
each subdir that will DTRT, at least as far as building the executables
goes.

I also have a preference that all of the executables and things end up
in the appropriate subdirs, because otherwise I fear (I haven't checked)
that the "target" directory will become way more populated than I want
to have to look at.

> The Automake manual is pretty clear about expectations for 'make dist'
> 
> https://www.gnu.org/software/automake/manual/automake.html#Dist
> 
> Particularly the statement:
> 
> "Note that when packages are nested using AC_CONFIG_SUBDIRS (see=20
> Subpackages), then =A1$(distdir)=A2 and =A1$(top_distdir)=A2 are relative=
>  to=20
> the package where =A1make dist=A2 was run, not to any sub-packages=20
> involved. "

Yes, I've been bitten by that before and the current "implementation"
works and accounts for this.

> If one has a non-recursive build then there is just one Makefile=20
> although a whole build system might be a mix of recursive and=20
> non-recursive methodologies.  In a non-resursive build, subordinate=20
> Makefile's are responsible for copying the files they are responsible=20
> for into the distribution.
> 
> It seems to me that strategies which are not compatible with=20
> Automake's own 'make dist' are not likely to work reliably.

I expect any solution for NTP will be some combination of different,
arcane, and intricate.

H

Re: converting to subdir-objects

[Harlan Stenn]

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 the toplevel-Makefile.am's tree should than also let 'make
> dist' work, shouldn't it?
> 
>> Harlan's posting here was due to Automake not working as he expected
>> for files which are not in a subdirectory so maybe it does not work.
> 
> Harlan, is your A/Makefile.am a sub-Makefile.am from a
> toplevel-Makefile.am, and thus all source files subordinate from this
> toplevel-Makefile.am?

In this case, I have a top-level Makefile.am, and the place where I'm
seeing the problem is in libntp/Makefile.am, which has traditionally
built libntp.a (a convenience library used by several other programs in
the distribution), and libntp.a is built from a whack of files in
libntp/ and also from a whack of files in lib/isc/*, where lib and
libntp are at the same level of the tree, and there are no Makefile.am
files in lib/ or any of its subdirs.

A truly bored person would grab a recent NTP tarball and just add
"subdir-objects" to the AM_INIT_AUTOMAKE line in the top-level
configure.ac (there are several places where we invoke configure.ac in
subdirs) and run either 'autoreconf' or the top-level ./bootstrap
script.

While I'd greatly appreciate any help on this, I don't expect anybody
else to be that ... motivated and I will, of course, keep slogging away
at this.

H

Re: converting to subdir-objects

[Harlan Stenn]

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 specifications outside 
> of the directory where the Makefile resides.
> 
> Perhaps the ability to use this successfully depends on the 
> implementation of the VPATH and target resolution support in the make 
> program (and possibly make program version) that your project is 
> specifically targeting.
> 
> I can not imagine 'make dist' or 'make distcheck' working properly if 
> source files are not subordinate to the directory containing Makefile. 
> How is 'tar' supposed to work?
> 
> Harlan's posting here was due to Automake not working as he expected 
> for files which are not in a subdirectory so maybe it does not work.

'make dist' and 'make distcheck' have been working fine for a Very Long
Time in this project.

In my attempt to get subdir-objects working NTP, I added
"subdir-objects" to the list of options in the AM_INIT_AUTOMAKE line in
its configure.ac file.  I figured I'd add that option, run autoreconf,
'make', and see what happened.

What happened was I got errors with the .deps stuff, and while I was
expecting to have to make some changes to the Makefile.am files, this
was not an issue I was expecting to see.

H

Re: converting to subdir-objects

[Harlan Stenn]

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.
> >
> > So if A/Makefile.am contains:
> >
> > foo_SRCS = ... $(srcdir)/../foo/bar.c
> 
> As far as I am aware, it is wise/required that source paths be 
> subordinate to the Makefile.am location (no .. bits).  All source 
> files are available under the Makefile (possibly via VPATH) so the 
> $(srcdir) bit is also harmful.  Perhaps there is some stylistic reason 
> to want to put the top-level Makefile in a subdirectory of the 
> project?

It's looked like this for decades.

There are several/many cases where a program or library in its
subdirectory wants a file from a "peer" elsewhere in the tree.

> Are you doing this so that there is one Makefile per program?

I prefer that as well.

> 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 in the source package.

I'll probably be doing that too, but at this point I'm looking at the
"include" solution more for a conversion to non-recursive Makefiles,
which I'm also not thrilled about because there are plenty of times I
want to go to a specific directory and run "make" and have it DTRT.

H

Re: converting to subdir-objects

[Harlan Stenn]

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 derivatitives).
> 
> 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.
> 
> So if A/Makefile.am contains:
> 
>  foo_SRCS = ... $(srcdir)/../foo/bar.c

and that should have been foo_SOURCES .

> I eventually see:
> 
> Makefile:XXX: ../../mydir/../foo/.deps/bar.Po: No such file or dierctory
> 
> I get this behavior with both FreeBSD's make and with gmake.  I am using
> VPATH.

in that automake sets up VPATH for me - I don't manually set it.

> 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!
> 

converting to subdir-objects

[Harlan Stenn]

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 derivatitives).

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.

So if A/Makefile.am contains:

 foo_SRCS = ... $(srcdir)/../foo/bar.c

I eventually see:

Makefile:XXX: ../../mydir/../foo/.deps/bar.Po: No such file or dierctory

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!

Re: The 'subdir-object' option breaks makefiles where foo_SOURCES contains $(var)

[Harlan Stenn]

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.
>
> (An aside: I see that ntp still uses a recursive Makefile setup.
> Given that you are about to mess with the ntp build system anyway,
> have you thought about trying to convert it to a non-recursive
> make setup?  That is the suggested way to go nowadays...)

I'd *love* to go non-recursive.  I've tried before, and haven't been
able to make it work.  The documentation wasn't there before, and my
brain didn't "see" what the new paradigm was trying to do.

> > I may wait until 1.15 is released to continue this effort.
>
> Well, actually, Automake 1.15 is already tagged in the Git repository
> and ready to be released (as soon as my new GPG key, replacing the one
> that expired 2 months ago, will be accepted by fpt-upl...@gnu.org).
> So this patch will not be available before Automake 1.16.  But then
> again, I believe the fix for this bug alone would be enough to
> justify a new minor Automake release, so don't worry, this fix will
> go in some release soon enough :-)

Fair enough, thanks!

> Also, more importantly, notice that this patch do not yet solve the
> issue of '.deps' directories and object files being created in the
> source directory (rather than in the build directory) for source
> files that contains an explicit reference to $(srcdir), when the
> 'subdir-object' option is enabled; see the still XFAIL'ing test
> 't/subobj-vpath-pr13928.sh'.

I'm likely seeing that problem too.

> This issue should *hopefully* be easy to fix, especially with the
> new dependency-bootstrapping logic; and I will try hard to make
> that happen before the 1.16 release.

Cool, thanks!

H

Re: The 'subdir-object' option breaks makefiles where foo_SOURCES contains $(var)

[Harlan Stenn]

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

Re: Automake 1.14 and subdir-objects

[Harlan Stenn]

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 issue directly, but this is a change I've
been dreading to make for the NTP sources for a while.  We don't do it
often, but the few times I've looked at the subdir-objects thing I've
come away thinking I want to avoid having to do this until I can see a
good solution.

H

Re: generated version numbers

[Harlan Stenn]

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 variable 
> $(ACLOCAL_M4). am__aclocal_m4_deps describes which files 'aclocal.m4' 
> depends on and depending on itself would probably have caused Make to 
> implode.

OK.

> > So we have a case where as a result of autoreconf running, aclocal.m4
> > gets updated and config.h.in does not get updated.  But the resulting
> > directory will require autotools (apparently the 'missing' stuff is
> > insufficient) because make*will*  force a rebuild of config.h.in because
> > aclocal.m4 is newer.
> 
> Correct. Are you saying that these time-stamps get propagated to a 
> distribution tarball. If so, it smells like the 'make dist' target could 
> get improved???

I'm saying that with the MAINTAINER_MODE stuff being different, now that
"missing" is no longer used by default there is a case where auto*'s
dependency rules for aclocal.m4 still require an autoheader run *after*
autoreconf has been run, and that seems to me to clearly be a bug.

H

Re: generated version numbers

[Harlan Stenn]

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.
>>
>> I suspect the answer is that at the end of the bootstrap script, if
>> the aclocal.m4 file is newer than the config.h.in file we need to
>> touch the config.h.in file.
>
> File 'config.h.in' is generated by autoheader [I assume]. Autoheader 
> will not touch the time-stamp of 'config.h.in' if the content doesn't 
> change. This can be annoying, and is the reason Automake generated rule 
> has a 'touch $@' after autoheader is called
> 
> $(srcdir)/config.h.in:  $(am__configure_deps)
>  ($(am__cd) $(top_srcdir) && $(AUTOHEADER))
>  rm -f stamp-h1
>  touch $@
> 
> In my bootstrap script I issue autoreconf with option '--force', so I 
> don't see this problem. If you think that is too expensive, you could 
> set environment
> variable AUTOHEADER with something like:
> 
> AUTOHEADER="autoheader -f" autoreconf -vi
> 
> Changing the behaviour of autoheader, I suspect will be met by some 
> significant resistance.

Yes, understood.  And the problem is that am__configure_deps includes
am__aclocal_m4_deps, which includes aclocal.m4.

So we have a case where as a result of autoreconf running, aclocal.m4
gets updated and config.h.in does not get updated.  But the resulting
directory will require autotools (apparently the 'missing' stuff is
insufficient) because make *will* force a rebuild of config.h.in because
aclocal.m4 is newer.

So perhaps autoreconf needs a late test that if aclocal.m4 is newer than
config.h.in, we touch config.h.in .

This way, if nothing is updated then nothing gets touched.  But if
aclocal.m4 gets updated we'll avoid this particular problem.

I think.  This stuff is, of course, intricate.

H

Re: generated version numbers

[Harlan Stenn]

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 15:10:03 2014 sntp/m4/version.m4
-rw-rw-r--  1 harlan  staff  41166 Feb 23 15:10:10 2014 aclocal.m4
-rw-rw-r--  1 harlan  staff  40943 Feb 23 15:10:15 2014 sntp/aclocal.m4
-rw-rw-r--  1 harlan  wheel  41378 Feb 23 15:10:30 2014 config.h.in
-rw-rw-r--  1 harlan  wheel  25706 Feb 23 15:14:16 2014 sntp/config.h.in
harlan@hms-mbp11% (update the repo)
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 15:10:03 2014 sntp/m4/version.m4
-rw-rw-r--  1 harlan  staff  41166 Feb 23 15:10:10 2014 aclocal.m4
-rw-rw-r--  1 harlan  staff  40943 Feb 23 15:10:15 2014 sntp/aclocal.m4
-rw-rw-r--  1 harlan  wheel  41378 Feb 23 15:10:30 2014 config.h.in
-rw-rw-r--  1 harlan  wheel  25706 Feb 23 15:14:16 2014 sntp/config.h.in
harlan@hms-mbp11% ./bootstrap
(update version.m4 if needed)
(touch man pages, sleep 1)
(touch .texi and .menu pages, sleep 1)
(touch .html pages)
(run autoreconf-vi)
autoreconf: Leaving directory `.'
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  41378 Feb 23 15:10:30 2014 config.h.in
-rw-rw-r--  1 harlan  wheel  25706 Feb 23 15:14:16 2014 sntp/config.h.in
-rw-rw-r--  1 harlan  wheel 40 Feb 26 10:06:09 2014 sntp/m4/version.m4
-rw-rw-r--  1 harlan  staff  41166 Feb 26 10:06:15 2014 aclocal.m4
-rw-rw-r--  1 harlan  staff  40943 Feb 26 10:06:21 2014 sntp/aclocal.m4
harlan@hms-mbp11%

so there it is - for some reason the config.h.in files are not being
regenerated.  Just to be clear, the script that generates m4/version.m4
only updates that file if the version number is different.  Right now,
version.m4 contains:

m4_define([VERSION_NUMBER],[4.2.7p425])

while the two config.h.in files contain:

harlan@hms-mbp11% grep VERSION sntp/config.h.in config.h.in
sntp/config.h.in:#undef PACKAGE_VERSION
sntp/config.h.in:#undef VERSION
config.h.in:#undef PACKAGE_VERSION
config.h.in:#undef VERSION
harlan@hms-mbp11%

There is no dependency on version.m4 for anything in the Makefile.am .

So automake has am__aclocal_m4_deps that does contain:

 $(top_srcdir)/sntp/m4/version.m4

which makes sense because the first line of configure.ac is:

 m4_include([sntp/m4/version.m4])

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.

I suspect the answer is that at the end of the bootstrap script, if the
aclocal.m4 file is newer than the config.h.in file we need to touch
the config.h.in file.

H

Re: Problems with gnits standard and git-version-gen

[Harlan Stenn]

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 releases) if we have to make
public snapshots and we are currently at 4.2.6p5 (old way, the new way
would be 4-2.6.5), we'd either be publishing a -betaN, -RCn, or release
upgade.

The progression might look like this:

 4-6.2.5
 4-6.2.6-beta1 (the first beta release that would become 4-6.2.6)
 4-6.2.6-RC1 (the first RC for 4-6.2.6)
 4-6.2.6

and I note that it doesn't sort well if we go from beta1 to RC1 to beta2
to beta3 to RC2.  At that point you'd need to look at the file
timestamps.  But we do our best to be very careful with changes to the
-stable branch so this is very rarely an issue.  And normal folks will
just wait for the production release.

This is not an issue for dev code because we can always bump the point
number there to make the order clear, and identify whether or not a
tarball is a release candidate or not.

H

perl modules

[Harlan Stenn]

So I've read the thread that ends with
http://lists.gnu.org/archive/html/automake/2011-12/msg00020.html .

I can make a choice about what to use for pmdir.

As part of the build and check process I want to run a generated perl
script that needs a module that I'll also be installing.  This means
that the module we want to use might not be installed, or the installed
copy might be an old copy.  We'll need to run the script in the build
tree and have it pick up the module we'll be installing.

I could use the PERL5LIB envariable and export that in the buld
Makefiles.  I'm not sure this will always work, but I just have an
intuitive concern about this.

I don't think I can use -I parameters to fix this because it would
require modifying the generated scripts.

I'm hesitant to

 use lib "..."

or

 BEGIN { unshift @INC ... }

to add the pre-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.

Suggestions?

-- 
Harlan Stenn 
http://networktimefoundation.org  - be a member!

Re: versions of automake

[Harlan Stenn]

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 were issues with older versions of automake that meant that while
> > *some* folks could use 1.10 or 1.11 for their builds, I recall knowing a
> > reason I could not.
> > 
> > ...
> > 
> > Anybody have some information for me?
> > 
> The NEWS file in the Automake tree? ;-)

Yay!  Thanks :)

H

versions of automake

[Harlan Stenn]

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 were issues with older versions of automake that meant that while
*some* folks could use 1.10 or 1.11 for their builds, I recall knowing a
reason I could not.

We're taking a look at bumping the required minimum version of automake,
and I was wondering if there was a list somewhere (other than the
ChangeLog) that would tell me what's going on with the different
releases so we could a) make a better decision, and b) 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!

Re: Is there a way to tell automake to not include rules for building .ps files from a .texi?

[Harlan Stenn]

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 digging to
remember this.

It would be helpful if there was a (built-in automake) check for texinfo
version to alert if this might be a problem.

Yeah, I'm not volunteering to write this - I'm mega swamped...

H

Re: Put GNU build system files in a subdirectory?

[Harlan Stenn]

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
> Makefile.am
> Makefile.in
> src <- This is my project
> 
> You think people are interested in the above [usual] setup?

Why not "lift" your project up a level so that all of the auto* stuff is
in what you call the 'src' directory?

H

Re: distclean should walk subdirs in reverse order

[Harlan Stenn]

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.
> 
> Non-recursive make systems can be a problem too. Anything can be a problem,  
> if it's not used properly. For any given tool there is a right way, and a  
> wrong way to use it.
> 
> And once codebase crosses some threshold, having one, flat Makefile just  
> does not work. I count 81 Makefile.am's in gcc's svn tree. Even if someone  
> comes up with one flat Makefile to replace all of them, I'd be shocked if  
> the end result is unquestionably superior.

I'm not suggesting a single flat file for a non-recursive Makefile
situation.

I'm expecting there to be one Makefile in each directory.

I'd also almost expect that the Makfile in each (build) directory would
"call up" to the top-level Makefile with enough information to build the
desired target.

I'd also expect that the top-level Makefile would "source in" enough
information from a file in each subdir (possibly not the Makefile) to
figure out the entire dependency and build situation.

H

Re: distclean should walk subdirs in reverse order

[Harlan Stenn]

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 makefile recursion.  For more background and rationales, see
> Peter Miller's excellent paper "Recursive Make Considered Harmful":
> 
> 
> See also the old similar issue:
> 
> 
> (Sorry for the overly curt reply, but time is what it is these
> days).

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.  I haven't found a useful
example of even the general case, where one invokes "make" from the
top-level build directory.  And to be actually useful, I'd want to be
able to go to any subdir of the build directory, invoke "make"  or "make
thing" and have the right stuff happen.

H

Re: vpath and make dist newbie problem

[Harlan Stenn]

List the .c and .h files in FOO_SOURCES.

H

Re: Makefile ignores source

[Harlan Stenn]

> 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

Re: dealing with executable shell scripts

[Harlan Stenn]

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

Re: dealing with executable shell scripts

[Harlan Stenn]

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

Re: dealing with executable shell scripts

[Harlan Stenn]

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 also do not use the "do_subst" trick
there; I name the files scriptname.in and let configure do the
substitutions for me, which means I pretty much only need bin_SCRIPTS in
the Makefile.am.  Since the "source" for the script is scriptname.in, I
don't have to wory about DIST issues.  I don't care about CLEAN issues,
either.  If I did I'd add ${bin_SCRIPTS} to CLEANFILES.

H

Re: dealing with executable shell scripts

[Harlan Stenn]

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
> > still have to add your own rules to handle all the actual work, need
> > to fiddle with EXTRA_DIST and CLEANFILES, etc.  Indeed, doing what I
> > did (putting the script in bin_PROGRAMS and adding a rule to build it)
> > actually seems _easier_, as automake will do more automatically, and
> > there's less to keep track of for the programmer
> 
> I recommend you actually try it and see for yourself.
> 
> There are reasons for using it for scripts instead of using _PROGRAMS.
> 
> H

... and try using as little as possible - I think you will be pleasantly
surprised.

H

Re: dealing with executable shell scripts

[Harlan Stenn]

> 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 handle all the actual work, need
> to fiddle with EXTRA_DIST and CLEANFILES, etc.  Indeed, doing what I
> did (putting the script in bin_PROGRAMS and adding a rule to build it)
> actually seems _easier_, as automake will do more automatically, and
> there's less to keep track of for the programmer

I recommend you actually try it and see for yourself.

There are reasons for using it for scripts instead of using _PROGRAMS.

H

Re: dealing with executable shell scripts

[Harlan Stenn]

What's the problem with bin_SCRIPTS?

H

Re: [gnu-prog-discuss] Could automake-generated Makefiles required GNU make?

[Harlan Stenn]

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?

> If the distrowatch.com stats are to be believed, *BSD's market share
> is under 1% that of Linux, which itself is only about 1% of the
> overall market of machines the Autotools can reasonably be used on.
> Further reduce that by the percentage of BSD boxes that have not yet
> had gmake installed after installation; 10% maybe?  We're probably
> talking about a set of boxes comprising < 0.001% of the market.  (10%
> of 1% of 1%.)
> 
> The hyperconservative autotools do drop backwards compatibility for 
> marginalized systems occasionally.  I seem to recall that some Ultrix 
> compatibility hacks were dropped recently, for example.
> 
> Not that I'm comparing modern BSDs to Ultrix.  They BSDs probably 
> couldn't be killed off at this point even if one wanted to.  Still, to 
> cater to the limitations of systems commanding something on the order 
> 0.001% of the market seems a *bit* obsessive.

There are %s and there are numbers.  And we all know what they say about
statistics.

I'm refraining, mightily and successfully, from escalating.  At least so
far.

H

Re: [gnu-prog-discuss] Could automake-generated Makefiles required GNU make?

[Harlan Stenn]

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 reasons.  I think we'd see a 
> change there PDQ if the autotools started requiring GNU make.

Just because you *can* be a gorilla doesn't mean you *should* be a
gorilla.

The BSDs have their good reasons to want to avoid GPL'd code, especially
GPL3.

H

Re: [gnu-prog-discuss] Could automake-generated Makefiles required GNU make?

[Harlan Stenn]

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, automake has not been using gmake, so why should
> it now start doing so?

- compelling, significant performance gains
- compelling, significant improvement in inter-package builds

are the two most obvious cases to me.

H

Re: [gnu-prog-discuss] Could automake-generated Makefiles required GNU make?

[Harlan Stenn]

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 started using automake as I wanted a way to have a single copy of
the source code with subdir build trees.  Metaconfig (the beast used by
Perl that I maintained for its "version 2" lifetime) did not have this
capability (and as I understand it, still doesn't).

NTP pretty much runs everywhere.  It was  not that long ago that NTP
dropped support for K&R C compilers, and at that point required ANSI C
(and I'm not sure if it's C89/C90 or C99, but nobody has complained so I
haven't looked harder).  Now that commodity x86 boxes are so "pervasive"
there is no longer a compelling reason to support things like ancient
sparc, mips, hp, ... boxes.

My goal is to make sure that people can easily build NTP.

Toward that end I want to minimize the number of extra tools that might
need to be installed.

I would not want to require GCC, for example.

We don't require perl, but if it is there we use it.

We do not require yacc-lex/bison-flex or GNU autogen for building.  But
if a developer wants to changes certain files, those tools will be
needed.

If there is a compelling reason to "upgrade" from current automake we'll
do it.

Some things I'd like to see would include easy non-recursive Makefiles
(that would let folks easily build any list of given particular
programs), and a means to integrate NTP into a larger build environment.
More generally, I'd love to see a widely-used framework that would make
it easy to create a "build" from a number of different separate
packages.

But I don't know what "friction" we'll be living with in the future, or
what friction we have now that will either get worse or go away.

Live and learn, if we're lucky...

H

Re: autoconf + automake support for MSVC

[Harlan Stenn]

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

Re: [GSoC conclusion] Two Branches for GSoC last valid changes

[Harlan Stenn]

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 evaluations, only work done up to that hour can be
considered for the final GSoC evaluation.

H

Re: Choosing man section at configure time

[Harlan Stenn]

Hi Stefano,

Thanks for the suggestion - it was pretty much along the lines I thought
I'd have to go before Ralf posted.

H

Re: Choosing man section at configure time

[Harlan Stenn]

Ralf,

That works just fine - thanks!

H

Choosing man section at configure time

[Harlan Stenn]

I'm trying to allow the selection of target man sections for each man
page at configure time.

For example, I have 'sntp.man.in' and 'sntp.mdoc.in' in the distribution
tarball, and at configure time "stuff happens" where the decision is
made as to which version (man or mdoc) of the manual is to be installed,
and also the manual section it should go in to.

I AC_SUBST([SNTP_MS]), and SNTP_MS will have the value "1", "1m", or
"8".

I also AC_SUBST([MANTAGFMT]), and MANTAGFMT is either "man" or "mdoc".

I have tried using the following in my Makefile.am:

 ...
 man_MANS=   sntp.$(SNTP_MS)
 ...
 sntp.$(SNTP_MS): $(srcdir)sntp.$(MANTAGFMT).in
sed -f m4/mansec.sed $(srcdir)sntp.$(MANTAGFMT).in > sntp.$(SNTP_MS)

and also:

 ...
 sntp.1 sntp.1c sntp.8: $(srcdir)sntp.$(MANTAGFMT).in
sed -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!

Re: GSoC project idea: non-recursive automake project

[Harlan Stenn]

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-recursive Makefiles for a project, I'd be willing to
> > > co-mentor and work with them to convert NTP to that sort of operation.
> >
> > It's mostly trivial. How hard are GSoC projects supposed to be?
> 
> Being a student, I'd be willing to prove it ;)

I'm happy to participate on this one, too.

H

Re: GSoC project idea: non-recursive automake project

[Harlan Stenn]

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 them to convert NTP to that sort of operation.
> 
> It's mostly trivial. How hard are GSoC projects supposed to be?

I'll assume you have seen my reply to Ralf.

>From my POV, I have heard folks saying for a long time how "easy" it is
to use automake to produce non-recursive Makefiles.  But I haven't seen
this in practice, and on the (few) attempts I have made to figure it out
myself and look for examples, I have not yet been able to find a really
useful solution.

What I think we'd want is a reasonably well-documented description of
how to use automake to produce a source tree where one can:

- run "make" from the top-level of the tree and all of the normal things
  happen (and all of the normal targets work)
- run "make" from a subdir, which would handle all of the normal targets
  for that subdir, and would also automatically handle *all* of the
  dependencies needed for the specified targets in that subdir (like
  prerequisite libraries).

H

Re: GSoC project idea: non-recursive automake project

[Harlan Stenn]

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 them to convert NTP to that sort of operation.
> 
> Thanks for the co-mentoring offer and the SoC idea!
> 
> I have a question though: how much work do you expect this to be?
> Haven't looked at NTP in a long time, but typically, turning a project
> into non-recursive was either a straightforward to trivial task of
> maybe 1-2 days for somebody experienced with autotools, or something
> difficult to impossible due to limitations in either of Make, Automake,
> or third-party bits.

If my goal was only to get a basic non-recursive Makefile setup going
for NTP, then yeah, I think it might be fairly easy.

Larry McVoy once said something like "In theory, theory and practice are
the same.  But in practice, they are not."

There are various "use" cases that should be explored - running make
from the top-level, running make from a subdir where a specific target
is asked to be built, etc.

The description, choices, and options should all be documented.

> Maybe such a proposal could be enhanced to avoid having not enough work:
> For example, while converting NTP, the student could start a document
> with a general recipe for this conversion.  And then maybe try it out on
> a couple more projects, and possibly refine the recipe along the way.
> For students that get very far, they could also try working on
> limitations in other tools should they come across them.
> 
> This way the student will not get bored.  However, it might be harder
> to define specific goals to achieve, or to define success in the end.

Yes, and I'd look at "making it 'go' on NTP" be part of the
proof-of-concept that we had a reasonably robust design with adequate
documentation.

> Would you be willing to formulate this as a proposal for the GNU
> proposals wiki page?

I think so, yes.  My "problem" is that I will only have a few hours'
time to work on this between now and this Monday, and I will probably
have no time from this Tuesday until the following Monday.

> I should note that I certainly don't have unlimited mentoring time.
> I expect to be able to mentor one student, and I'm sure co- or backup-
> mentoring beside that should be possible, but if we can find another
> person to help that would only be good.

Yup, I suspect I'll be at my "maximum load" for GSoC this year, too.

H

GSoC project idea: non-recursive automake project

[Harlan Stenn]

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!

Re: [GSoC Proposal] automake - Interfacing with a test protocol like TAP or subunit

[Harlan Stenn]

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

Re: ACLOCAL_PATH patch?

[Harlan Stenn]

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 longer need
the path.

While I'm tempted to ask what I can do to help move this along, I'm
massively crunched for time right now.

Since I'm not planning to do anything "creative" with this
functionality, I'll probably just try the patch chain that Paolo posted
(in the thread Stefano mentioned above) and see how that works for me.

Thanks again...

H

ACLOCAL_PATH patch?

[Harlan Stenn]

http://www.mail-archive.com/automake-patches@gnu.org/msg00873.html
describes a patch I once asked for.  I did a search in the
automake-1.11.1 codebase and I don't see any mention of ACLOCAL_PATH in
there at all.

My interest in an environment variable to handle this case (for the
reasons 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!

Re: Autotools GSoC ideas

[Harlan Stenn]

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 then becomes more difficult to figure out
if the student really knows what they are doing (or not).

If the written proposals offer a direction and some stepping points
(only), then the students have a chance to "fill in the blanks" and it
becomes much easier to identify these "better" students.

Just my opinion.

H

Re: High-Precision NFS Timestamps

[Harlan Stenn]

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

Re: Sun compiler and /usr/local/include

[Harlan Stenn]

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 better way to go...

H

Re: cannot specify -o with -c or -S

[Harlan Stenn]

Richard,

Why are all the header files from Projects/subA/ being enumerated in the
compile line?  I think that's the problem.

H

Re: using ntp??

[Harlan Stenn]

Oh, you are probably using NFS for this - ntpd will need to be running
on the NFS server and your local box.

H

Re: using ntp??

[Harlan Stenn]

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 links even
better.

You can also find online help at irc://irc.freenode.net/#ntp .

H

Re: ifdef expessions in Makefile.am

[Harlan Stenn]

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

writability of directories in distributions

[Harlan Stenn]

I just saw a patch go by about changing the perms on directories in
distribution tarballs.

I'm a fan of 775 myself (ok, I really prefer 2775).

But I can see that some would prefer 777, and others would prefer 755.

The other issue, as I recall, has to do with whether or not 'root' is
doing the unpacking.

While there is something to be said for letting the package maintainer
make this choice, there is also clearly something to be said for letting
the recipient make the choice.

I suspect that leaving the current behavior alone will irritate some,
and changing the current behavior will irritate others.

We can only go so far with "solving" this problem at distribution time.

I'm not ready to suggest we have a DIST_DIRMODE value, as I'm not sure
how useful it would be.

Likewise, I'm not sure we should have a pkg_dirmodes script that gets
bundled with the tarballs that folks could run to set the directory
perms the way they want them.  Specifically on this point, should we
limit the effects of this script to directory modes, or should it
adjust file perms as well?

To the extent my vote counts for anything, my preference would be to
discuss 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!

Re: When did abs_builddir show up?

[Harlan Stenn]

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

When did abs_builddir show up?

[Harlan Stenn]

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!

Re: Difficulty cross-compiling

[Harlan Stenn]

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

Re: Controlling the order of compilation

[Harlan Stenn]

Umut,

Check out the BUILT_SOURCES variable.

H

Re: DESTDIR vs `make install exec_prefix='

[Harlan Stenn]

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=/usr/local
>   make
>   make install exec_prefix= DESTDIR=/tmp/dest
> 
> most likely copies executable files into the /tmp/dest directory, which
> doesn't seem desirable either.  So, for both of these cases, Automake
> 1.11 will not install executable files at all.
> 
> This change in funtionality only affects cases where an installation
> directory has been set to the empty string.  It should not affect your
> use case for stow at all.
> 
> Hope that clears this up.

Reading the doc pages for automake, it looks like automake should not
install *anything* if either prefix or exec_prefix is the empty string,
under any circumstances.

So if one was trying to effect some interesting local policy described
above,

   make install exec_prefix=/ DESTDIR=/tmp/dest

or

   make install prefix=/ DESTDIR=/tmp/dest

would be the way to do that, right?

H

Re: DESTDIR vs `make install exec_prefix='

[Harlan Stenn]

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, only $(bindir) etc.
> 
> I must have misunderstood this, since it sounds like it would potentially
> break any system where each binary package is installed into a separate
> tree.  For example, stow packages are routinely installed with:
> 
> ./configure --prefix=/usr/local
> make
> make install prefix=/usr/local/stow/package-version
> 
> DESTDIR cannot easily be used here because the stow layout should have
> simple bin, etc, lib, etc. directories directly under that directory, not
> with an extra /usr/local in the way.

I know that GNU coding standards really want package developers to allow
one to be able to override the prefix at "make install" time and "it
should just work".  While I appreciate the goal and sentiment, sometimes
that just isn't easy or feasible to do.

When I build packages for the modules.sourceforge.net project (similar
to stow) I just make a point of running configure with the --prefix set
to the actual installation/execution path.

In this case I may use DESTDIR for one of two purposes:

- I want to install it "somewhere else" so I can tar up that subtree and
  unpack it later into the correct place
- I have to sneak the installation into a different place to install
  under a tree that accomodates am-utils and NFS-mounting the
  executables for a specific target architecture, and I keep all the
  "installed packages" for all the target architectures on a single
  partition.

For me this entire discussion smacks of some "fuzzy edges" between
mechanism (where to put things, and the spsecification of how the code
figure out where to look for things) and policy (where to put things,
and the specification of how the code figure out here to look for
things).

H

Re: blank line following trailing backslash

[Harlan Stenn]

* 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 "sort" the filenames.

I hope I followed this thread correctly.

H

Re: Helper script && noinst_SCRIPTS

[Harlan Stenn]

> 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.sh
> in tests/Makefile.am
> 
> Of course I don't want to install this script (by make install).
> So, I added
> noinst_SCRIPTS = fds_by_process.sh
> in tests/Makefile.am.

I think you may want to use only one _SCRIPTS line:

 dist_check_SCRIPTS = fds_by_process.sh

but I could be wrong.

The dist_bin_scripts means "distribute the scripts *and* install them in
bindir".

H

Re: How to install shell script?

[Harlan Stenn]

> 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'
> 
> Did you miss somthing?

Yes.

So you will need to create a new target:

foodir=$prefix/etc

foo_SCRIPTS= ...

I could be making another mistake here, but it's also documented.

H

Re: How to install shell script?

[Harlan Stenn]

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 executable.  How do I
> make it happen?  Thanks.
> 
> -
> woody
> 

Re: parallel make help

[Harlan Stenn]

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 is that all 
> of the paths need to be completely specified (from the top), but 
> modified to work with Automake.

While it is "too late now" for this round of GSoC, it might be a really
amazing idea to have somebody work on a project to:

- make sure automake has all the needed bits to produce useful
  non-recursive Makefiles
- demonstrate how easy it is to set this up and convert existing
projects

H

Re: How do I configure Makefile.am to run a program?

[Harlan Stenn]

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 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
> > template
> > > file (.tmpl) and writes out the .spec file after calling subversion .
> > -n.  I
> > > can't figure out how to force make from a Makefile.am to run the perl
> > script
> > > each time it builds.
> > > I thought I could do it with SUFFIXES but when I tried it didn't work.
> >  I
> > > added the following to the top level Makefile.am:
> > >
> > > noinst_PROGRAMS = poll.spec
> > > poll_tmpl_SOURCES = poll.tmpl FORCE
> > > .tmpl.spec:
> > >./logpoll.pl $<
> > >
> > > FORCE:
> >
> > You want BUILT_SOURCES = something.
> >
> > If logpoll.pl takes the .tmpl.spec file and spits out 'poll.spec' then
> > you want:
> >
> > BUILT_SOURCES = poll.spec
> >
> > poll.spec: .tmpl.spec logpoll.pl
> >   ./logpoll.pl $<
> >
> > if logpoll.pl is a generated script.  If it's part of the package you
> > want:
> >
> > poll.spec: .tmpl.spec
> >   $srcdir/logpoll.pl $<
> >
> > H
> >
> > I tried but I got:
> 
> Makefile.am:16: variable `BUILD_SOURCES' is defined but no program or
> Makefile.am:16: library has `BUILD' as canonic name (possible typo)
>  cd . && /bin/sh ./config.status Makefile
> config.status: creating Makefile
> Makefile:671: warning: overriding commands for target `poll.spec'
> Makefile:256: warning: ignoring old commands for target `poll.spec'
> make  all-recursive
> make[1]: Entering directory `/home/jlynch/threaded'
> Makefile:671: warning: overriding commands for target `poll.spec'
> Makefile:256: warning: ignoring old commands for target `poll.spec'
> Making all in src
> 
> I think I did what you suggested, from my Makefile.am
> 
> BUILD_SOURCES = poll.spec
> 
> poll.spec: .tmpl.spec logpoll.pl
> ./logpoll.pl $<
> 
> noinst_DATA = poll.spec
> 
> logpoll.pl is a static script that simply reads the tmpl file, runs
> svnversion to get the version number and does a substitute and writes the
> spec file.

Re: How do I configure Makefile.am to run a program?

[Harlan Stenn]

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 file for me.  I wrote a small perl program that reads a template
> > file (.tmpl) and writes out the .spec file after calling subversion . -n.  
> I
> > can't figure out how to force make from a Makefile.am to run the perl scrip
> t
> > each time it builds.
> > I thought I could do it with SUFFIXES but when I tried it didn't work.  I
> > added the following to the top level Makefile.am:
> > 
> > noinst_PROGRAMS = poll.spec
> > poll_tmpl_SOURCES = poll.tmpl FORCE
> > .tmpl.spec:
> >./logpoll.pl $<
> > 
> > FORCE:
> 
> You want BUILT_SOURCES = something.
> 
> If logpoll.pl takes the .tmpl.spec file and spits out 'poll.spec' then
> you want:
> 
> BUILT_SOURCES = poll.spec
> 
> poll.spec: .tmpl.spec logpoll.pl
>  ./logpoll.pl $<
> 
> if logpoll.pl is a generated script.  If it's part of the package you want:
> 
> poll.spec: .tmpl.spec
>  $srcdir/logpoll.pl $<
> 
> H
> 
>  
> 

Re: How do I configure Makefile.am to run a program?

[Harlan Stenn]

> 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 template
> file (.tmpl) and writes out the .spec file after calling subversion . -n.  I
> can't figure out how to force make from a Makefile.am to run the perl script
> each time it builds.
> I thought I could do it with SUFFIXES but when I tried it didn't work.  I
> added the following to the top level Makefile.am:
> 
> noinst_PROGRAMS = poll.spec
> poll_tmpl_SOURCES = poll.tmpl FORCE
> .tmpl.spec:
>./logpoll.pl $<
> 
> FORCE:

You want BUILT_SOURCES = something.

If logpoll.pl takes the .tmpl.spec file and spits out 'poll.spec' then
you want:

BUILT_SOURCES = poll.spec

poll.spec: .tmpl.spec logpoll.pl
   ./logpoll.pl $<

if logpoll.pl is a generated script.  If it's part of the package you want:

poll.spec: .tmpl.spec
   $srcdir/logpoll.pl $<

H

   

Re: Shared without libtool

[Harlan Stenn]

> 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 somebody else (libtool) deal
with the shared library issues, it is usually much easier to let libtool
deal with it.

If you already have (and expect to be keeping) a group of folks who are
ready to fight the "shared library battles" it may be worth letting them
keep doing it, even under automake.

There is suckage either way.

Speaking as somebody who dislikes messing with the details of shared
libraries on a bunch of platforms, and also as somebody who (from a
place of ignorance) wonders why it takes so long to get new releases of
libtool out, I would be Thrilled if the folks you know who want to do
their own shared-library stuff under automake would instead work on
making libtool even better so the rest of us can benefit from that
effort as well.

H

Re: substitution vs expansion in Makefile.am

[Harlan Stenn]

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 do it is to use "$(top_srcdir)/common/mySleep.c"
> which will work under all circumstances.

I have years of experience and many examples that agree with me and not
with you.

The VPATH includes the SRCDIR, and as long as ../common/mySleep.c is
correct from the source tree, it will work in a build tree.

In my experience.

H

Re: substitution vs expansion in Makefile.am

[Harlan Stenn]

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/mySleep.c, don't I, as it's in a different source
> directory?

You can use: ../common/mySleep.c in your foo_SOURCES list.

H

Re: source code type detection

[Harlan Stenn]

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 `CXX' is to add `AC_PROG_CXX'
> Makefile.am:   to `configure.ac' and run `autoconf' again.
> 
> So I guess automake interprets b.C to be C++. How can I tell automake
> that it's really C?

Make a BUILT_SOURCES rule that links/copies $(srcdir)/b.C to
($builddir)/b.c and use b.c in your foo_SOURCES line.

H

Re: Automake (alpha) release request

[Harlan Stenn]

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,
> where the latest released version is not good enough, and if there is
> an expectation that the FSF lawyers might take a while still, then
> would it be feasible simply to release automake under the GPLv3
> *without* those troublesome exceptions?  Doing so would not burden
> other free software projects which are already GPLv3 themselves.

Except there will be a version of automake out there that has
significantly different licensing requirements from other versions of
automake.

> Just which projects are clamouring for a new automake release - and
> under what licence do they wish to distribute their makefiles +
> aclocal.m4?

I'm not clamoring for a new automake release.  I also generally release
code under a BSD license that has (so far) been usable by folks who
themselves prefer GPL.  And having a version of automake out there that
does not have the license exceptions will give me a major chill.

So far this project has done a real good job of being both useful and
usable, and generally staying out of the licensing wars.

I most strenuously hope we continue to stay out of the licensing wars,
as the alternative is, at least for me, most unpleasant, and will create
significant hardships for *many* people.

H

Re: NFS--mounted builddirs and detecting clock skew

[Harlan Stenn]

And of course, NFS file attribute caching can make detecting clock skew
a whole lot more interesting.

H

Re: NFS--mounted builddirs and detecting clock skew

[Harlan Stenn]

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
> 
> NFS1 (Sources)
>   /
>CPU
>   \
> NFS2 (Built Objects)

I haven't used this, but if 'make' on the CPU system will have one idea
of timestamps, and files on NFS1 and/or NFS2 can show clock skew that
will affect how 'make' on CPU runs, then yes.

> or
> 
> Local Disk (Sources)
>   /
>CPU
>   \
> NFS2 (Built Objects)

Again, if 'make' on CPU system will be adversely affected by clock skew
on NFS2 then this should be checked.

> or
> 
> NFS1 (Sources)
>   /
>CPU
>   \
> Local Disk (Built Objects)

As above.

> I use the last one quite often these days but sometimes I use the 
> first.

There seems to be several issues here.  Is the following a usefully
sufficient question to ask:

 If I touch a file now, how far off is the timestamp on the file I touch
 from what I think the time is?

Taking your above examples into consideration, there is the added
complication of "what if srcdir is unwritable?"

> >> When my clocks are a bit off I have noticed that
> >> GNU make sometimes intermittently complains due to the "wandering
> >> clock" problem.
> >
> > I don't see 'wander' (case insensitive) in either the gmake 3.81 or
> > 3.79.1 source trees.
> 
> What I mean is that the condition is borderline detectable so 
> sometimes it is detected and other times not.

Yes, this all boils down to the meaning of "detectable".

At the moment, I am inclined to think that if 'make' will detect it,
then I care.  And this is clearly an insufficient definition.  Perhaps
the 'check-clock-skew' program would have a "useful" default threshhold,
and there could be an option to specify a different threshhold.

H

Re: NFS--mounted builddirs and detecting clock skew

[Harlan Stenn]

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 that hosts the  actual filesystem (NFS
> > server box).
> 
> I suggest that you check out some cool software called xntp which can 
> help correct your clock skew problems.

Good idea - thanks!  Where might I learn more?

More to the point, I'm discussion an issue separate from NTP.  I am
trying to *detect* an existing problem condition, not prevent the
problem.

> > If I am running a configure script and there is a clock skew problem, I
> > would want to know this ASAP beacuse if the clock skew is not
> > deliberate, I want to fix it Right Away.
> 
> Which particular clock skew do you want to detect?
> 
>* Clock skew to source directory
>* Clock skew to build directory
>* Clock skew to header files outside the source directory
>* Clock skew to libraries outside the build directory
>* Clock skew to temporary file directory (gasp!)
>* Clock skew due to filesystem with 1 second time resolution
>* Clock skew during build due to wandering clock
>* Clock skew to parallel build machine
> 
> All of these problems are possible.  Some issues are seen by GNU make 
> and others are not.

I *think* I'd be happy with 'clock skew in the build directory'.

If there are ways to use the same core functionality to measure the
other cases you metion, that would be great.

> When my clocks are a bit off I have noticed that 
> GNU make sometimes intermittently complains due to the "wandering 
> clock" problem.

I don't see 'wander' (case insensitive) in either the gmake 3.81 or
3.79.1 source trees.

> If I am not imagining things, I have seen configure 
> complain about clock problems before so perhaps there is already a 
> sanity check in place.

AM_SANITY_CHECK will test to see if a newly-created file is older than
distributed files, but that is more of a system clock check than a clock
skew check.

H

NFS--mounted builddirs and detecting clock skew

[Harlan Stenn]

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 be value in:

- a small script/executable that can detect a clock skew problem
- a configure test that sees if there is currently a clock skew problem
- a Makefile test that can detect a clock skew problem

The first item above could be used by the other two, and also by other
scripts that might care about this issue.

Background: I am being bitten by a clock skew problem in an environment
where it is sometimes a feature that clock skew exists.  When it exists,
however, there are still some operations that (properly) consider clock
skew to be a bug, and want to detect this condition, squawk, and
terminate.

If I am running a configure script and there is a clock skew problem, I
would want to know this ASAP beacuse if the clock skew is not
deliberate, I want to fix it Right Away.

Once I have run configure, my automake-based systems would benefit from
a rule in the Makefile that would let me know if there is clock skew.
Some of these systems are not running gmake.  And even if they are
running gmake, a rule that detects clock skew lets me take explicit
action.

I have some release-engineering scripts I use where it would also be
useful to know if there is a clock-skew problem.

Hmmm, I'm now thinking it might be useful to offer a small package along
these lines, where 'check-clock-skew' was implemented as C code, perl
(script and module), sh, and perhaps whatever else folks thought was
worth donating could be distributed.

So thoughts/ideas?

H

Re: Another snag.. extension detection

[Harlan Stenn]

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

Re: Detecting FreeBSD's make

[Harlan Stenn]

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 understand it) using VPATH searches
for built files.

Thomas Dickey says his latest byacc includes fixes that are not in the
stock FreeBSD byacc and he does not get the problem I do with his code.

I expect this particular situation (like so many others) is a 'wart'
that will only be seen for a certain period of time.

H

Re: Detecting FreeBSD's make

[Harlan Stenn]

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
> correctly supports out-of-the-tree builds is GNU make.  The VPATH
> capability in every other version of make that I'm aware of, including
> BSD make and SysV make, is just plain borked (IMNSHO).

IME, that position is excessive.  It was true, as far as I can recall,
for SGI's make, but this is the first time this particular issue has
bitten me (or any of the users of the package) in a *long* time.

> My personal suggestion would be to follow that advice and simply
> document that out-of-the-tree builds are not supported by your project
> unless the user uses GNU make.

That probably won't happen in this case - we'll either figure out the
compatibility issue between bison and byacc or I'll figure out how to
get the 2 files I need into the right build directory.

> It's very difficult for autotools to detect and work around make issues,
> because there's absolutely no guarantee that the "make" program that
> autoconf/etc. finds and uses will be the one the user actually invokes
> to build the project.  Users are not accustomed to saying "./configure
> MAKE=gmake" or similar.

As far as I'm concerned, the version of 'make' that is found by
configure will be the same 'make' that the user invokes.  If that is not
the case and I hear about it I will lart the user.

And I had code in configure.ac to see if 'make' was gmake or not and I
removed that code when ancient SGI (if that's what it was) went away.  I
can always "recover" that old code.

H

Detecting FreeBSD's make

[Harlan Stenn]

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 the corresponding .y->.[ch]
files from its vantage point in the builddir, so it fires up byacc to
generate the files.

The byacc-generated parser code is different from what bison produced,
and we get a "syntax error" parsing the target file.  Yes, we want to
find and fix this discrepancy.  We also want to improve the parsing
error messages.

And as a work-around (at least), if I can detect that the build
environment is using a 'make' that has this VPATH difference, I can go
ahead and copy/link the generated .[ch] files from the srcdir into the
builddir and also "solve" the problem that way.

Thoughts/suggestions?

H

Re: -pipe passed to gcc via Automake

[Harlan Stenn]

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
bunch of checks being done, it can be significantly faster to use 'case'
instead of 'test'.

Disclaimer: I have been doing this for Years (I picked it up from Larry
Wall sometime before I took over the maintenance of metaconfig) and have
not tested it lately.

H

Re: Makefile.am assistance

[Harlan Stenn]

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

Re: AC_PROG_CC sets CFLAGS, what about AM_CFLAGS?

[Harlan Stenn]

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 (that can be safely overridden by the user)
> 
> What's wrong with this?

It gives the user more things to type.

H

Re: Automake violations of the gnu coding conventions

[Harlan Stenn]

> 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.  Shorten the 
> developer cycle at the cost of the usability.  I was hoping that enough 
> time had elapsed that it might be reasonable to reevaluate this priority.

You have not communicated to me how the current situation costs
usability.

I am certainly open to win/win solutions, however.  I'm even open to
solutions that "cost" me at a clear benefit to others.

I just haven't seen how this is the case based on what I have read from
you.

It may not matter, as I am not an automake maintainer.

> > I'm saying "mitigate the onus".
> >
> > While it's debatable if your deviation is trivial, speaking from my
> > experience implementing your proposal will definitely cost me time and
> > effort, and I do not see any offsetting general benefit.

> The general benefit is in usability.

Please help me to understand, as I'm not seeing it.

> > I agree with Ralf - can you demonstrate an example of the problem you
> > are trying to solve?

> I've already described the use case twice.  And the response seems to be 
> that automake doesn't support those use cases.  Ok, I knew that.  
> Automake doesn't support those use cases YET.  What I'm proposing is 
> that we start supporting those use cases, directly, as a standard and 
> supported feature of automake.

OK, I'll re-read again in about an hour (errand time for me).

> >> In what way does my proposal fail to address your needs?

> > Where is the trivial way I can change your default policy so I can work
> > as efficiently as I do now?

> Yes.  Add AM_REGEN to your Makefile.am.

I'll read again, and I don't see how this does it, unless you are saying
make AM_REGEN the default case and have the "make dist*" supply an
overriding parameter to configure to have it not produce those rules in
the distributed Makefile.in files.

> > Telling me to remember to run a different target is not good enough.

> And telling me that I must have automake installed simply in order to 
> build packages that use automake really isn't good enough either.

But as Ralf said you don't need to have automake installed.  The
'missing' script handles this case, and there must be some reason why
your timestamps are getting messed up as I have never seen a failure
case like the one you are describing either.

And this situation is even more layered - I am using GNU AutoGen for one
big project, and I do not want to require my other developers to install
it.  Therefore I check in my autogen-generated files and we use a
'bootstrap' script after doing a code checkout to make sure the
timestamps are OK.  I have a similar situation where this same package
must be developed on stock Windows boxes, so I also check in the files
generated by yacc/bison.

I'd love to have a better solution to these problems, but at least I
have a workable solution.

H

Re: Automake violations of the gnu coding conventions

[Harlan Stenn]

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
an extra step to make sure that generated files are up-to-date is just
asking for more work and problems.

Put another way, if somebody want to have sufficient mechanism to allow
these behaviors as choices, and if somebody wants to have a way to
specify that strict GNU coding policy can be used that's fine with me.
Just be sure to make it trivial enough that I can override that policy
choice locally so I can work more efficiently.

H

Re: Automake violations of the gnu coding conventions

[Harlan Stenn]

> 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 as a release engineer.
> >
> > I already have way too much stuff I have to remember to do, and adding
> > an extra step to make sure that generated files are up-to-date is just
> > asking for more work and problems.

> distcheck could also be used to verify this based on file stamps and to 
> provide a reminder.

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.

> > Put another way, if somebody want to have sufficient mechanism to allow
> > these behaviors as choices, and if somebody wants to have a way to
> > specify that strict GNU coding policy can be used that's fine with me.
> > Just be sure to make it trivial enough that I can override that policy
> > choice locally so I can work more efficiently.

> I think we're all agreed on this.  The question is whether the onus for 
> difference should be placed on the user or on the developer.  In both 
> cases, the deviation is intended to be trivial.  However, a developer is 
> expected to understand that the change is necessary and how to make it 
> while a simple builder may not.

I'm saying "mitigate the onus".

While it's debatable if your deviation is trivial, speaking from my
experience implementing your proposal will definitely cost me time and
effort, and I do not see any offsetting general benefit.

I agree with Ralf - can you demonstrate an example of the problem you
are trying to solve?

> In what way does my proposal fail to address your needs?

Where is the trivial way I can change your default policy so I can work
as efficiently as I do now?

Telling me to remember to run a different target is not good enough.

H

Re: Make dist problems

[Harlan Stenn]

'make distcheck' can also be your friend.

H

Re: generated ChangeLog

[Harlan Stenn]

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 describing each bug fixed, new features, etc).

The CommitLog file is auto-generated from our code-management system.

This mostly works well enough for me now.  Mostly.

H

Re: nobase.test

[Harlan Stenn]

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 call to install-sh.  
> 
> And if why stop with install-sh?  Any reason mdate-sh, ylwrap, and
> friends should be handled differently than install-sh?

Re: false positive result with 'make distcheck'

[Harlan Stenn]

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 -pi -e s'|[EMAIL PROTECTED]@|$(sysconfdir)|' \
> > > < $(srcdir)/rpmbuildupdate.in > $@
> > > 
> > > rpmbuildupdate.comp: rpmbuildupdate.comp.in
> > >   perl -pi -e s'|[EMAIL PROTECTED]@|$(sysconfdir)|' \
> > > < $(srcdir)/rpmbuildupdate.comp.in > $@
> > > 
> > > (Note that even Solaris make would not VPATH-rewrite the rule, since the
> > > string `rpmbuildupdate.in' is not surrounded by white space in the rule.)
> > 
> > This way will not work if one wants the generated Makefiles to be useful
> > on several non-GNU versions of "make".
> 
> Yes it will.

OK, I know I had good reason to add $(srcdir)/ to some targets
(dependencies?) and at the time, I did not add it to others (because at
the time, "things worked").

I consequently got screwed with both FreeBSD and Solaris make, for
different reasons.

The problem was solved when I consistently added $(srcdir)/ before every
instance of "foo" for targets, dependencies, and in rules (the latter
was because of Solaris 'make').

> > As I recently learned, if one uses $(srcdir)/foo as a target or a
> > dependency, one must use it in all places "foo" is referenced (including
> > on the command line rule of a target, or Sun's "make" (for example) will
> > do Interesting things.
> 
> Yes, I think I mentioned that in the message you quote.  The above will
> work with Solaris make: all instances of `rpmbuildupdate.in' in the
> rule are _not_ surrounded by whitespace: there is a `/' right before
> them.  So they are not rewritten in this case.

'k.

> But you are right that all instances of `rpmbuildupdate.in' in targets
> or prerequisites should also not be prefixed with `$(srcdir)/' so other
> make implementations won't think they are two different things (and note
> that $(EXTRA_DIST) occurs as prerequisite in a generated rule).  I think
> I noted that too, though.
> 
> What am I missing?

Probably nothing - I may have read what you wrote "differently" from
what you intended.  I was concerned about your first case - if somebody
goes to the trouble of putting a $(srcdir)/ on a target or a dependency,
they need to be either "most everywhere" or nowhere.

This may not be true, but it is a rule I currently accept.

H