stamph processing fix

Hi! Akim told me awhile back to port forward and resubmit some patches if I noticed that they hadn't been accepted after some time had passed. Anyway, it's been awhile, so here's a resubmission of the patch that fixes the stamp-h? processing which configure is currently doing. Basically, the old

Re: depcomp problem [Fwd: Trying to compile latest CVS on old SCO unixware 2]

Stephen Cameron wrote: > It's getting a bit weird now, > > Making all in lib > source='argmatch.c' object='argmatch.o' libtool=no \ > depfile='.deps/argmatch.Po' tmpdepfile='.deps/argmatch.TPo' \ > depmode=none /bin/sh ../depcomp \ > ../compile cc -DHAVE_CONFIG_H -

depcomp problem [Fwd: Trying to compile latest CVS on old SCO unixware 2]

Sounds like this could be fixed in depcomp? Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] CollabNet ( http://collab.net ) -- "Very funny Scotty, now beam down my clothes!" Hi, I'm Trying to update an old SCO unixwa

Re: AC_CONFIG_AUX_DIR now required when mdate-sh resides in subdir?

Jim Meyering wrote: > Hi Derek, > > Recently, automake changed so that I get the following in fileutils-4.1, > even though I've put a copy of mdate-sh (though not in the official tarball) > in doc/. > > $ automake --gnits --include-deps > doc/Makefile.am:2: required file `./mdate-sh' not foun

Re: aclocal doesn't check AUTOMAKE_OPTIONS (VERSION)

Akim Demaille wrote: > > "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes: > > Tom> We're planning to get rid of aclocal in the future. I forget > Tom> exactly what form that plan takes. Akim knows. > > First of all, the responsibility will move to Autoconf, aclocal has > nothing to do with A

aclocal doesn't check AUTOMAKE_OPTIONS (VERSION)

In the manual, it is specified that if there is a version string in the AUTOMAKE_OPTIONS Makefile macro in Makefile.am, this will suppress running of older versions of Automake. Source can break anyhow since versions of aclocal earlier than the specified version will run anyhow and build an acloc

Re: possible bug with depcomp

Akim Demaille wrote: > > "Robert" == Robert Collins <[EMAIL PROTECTED]> writes: > > Robert> The project I'm converting to automake uses > Robert> AC_CONFIG_AUX_DIR(cfgaux). The dependency cehcking code was > Robert> looking for depend in the srcdir, not the srcdir/cfgaux. I'm > Robert> using

Re: Default postscript cleans miss *.cps & *.fns.

Akim Demaille wrote: > elsif (/^\@syncodeindex \w+ (\w*)/ > || /^\@printindex (\w+)/) > { > push @clean_suffixes, "$1s"; > } Yep. That works. > IIRC, you also had problems with fns. What does a `grep fn *texi*' gives? Not much obviously useful, but you

Re: Default postscript cleans miss *.cps & *.fns.

Akim Demaille wrote: > > "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes: > > > "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes: > Akim> elsif (/^\@(syncode|print)index \w+ (\w*)/) { push > Akim> @clean_suffixes, "$1s"; > > Tom> Shouldn't that be "$2s" here? > > Yes, definitely. Thanks

Re: overriding tested automake & aclocal in test suite

Tom Tromey wrote: > >>>>> "Derek" == Derek R Price <[EMAIL PROTECTED]> writes: > > Derek> Is there some reason the automake test suite doesn't allow the > Derek> user to override its AUTOMAKE & ACLOCAL variables? > > Thanks for the

Re: overriding tested automake & aclocal in test suite

Tom Tromey wrote: > >>>>> "Derek" == Derek R Price <[EMAIL PROTECTED]> writes: > > Derek> Is there some reason the automake test suite doesn't allow the > Derek> user to override its AUTOMAKE & ACLOCAL variables? I like to > Derek&

depcomp bug (was [Fwd: CVS update: ccvs])

ailto:[EMAIL PROTECTED] CollabNet ( http://collab.net ) -- Boy: A noise with dirt on it Derek R. Price writes: > > * depcomp: Don't count on $? being set in then or else clauses. > > What system is this happening on? depcomp is part of the Automake > distribution

overriding tested automake & aclocal in test suite

Is there some reason the automake test suite doesn't allow the user to override its AUTOMAKE & ACLOCAL variables? I like to do it on ocassion to compare the current behavior against my installed version and the like. Derek -- Derek Price CVS Solutions Architect ( http://CVS

Re: Default postscript cleans miss *.cps & *.fns.

Akim Demaille wrote: > | Akim Demaille wrote: > | > | > Could you `grep indexcode' your texi sources? Thanks! > | > | [dprice@empress doc]$ fgrep indexcode cvs.texinfo > | [dprice@empress doc]$ > > Actually I meant _all_ your sources. And in fact, @include would be > useful too. Sorry

Re: FYI: On the way to -w

Akim Demaille wrote: > Tom Tromey <[EMAIL PROTECTED]> writes: > > > What remains in order to enable `use strict'? [. . .] > > $require_file_found{'depcomp'} = 1 if -f "$depcomp_dir/depcomp"; > > it is because of this guy. It should not be used directly here, but > to fix this proper

Re: BSD Make

eachers. I am not authorized to fire substitute teachers. I am not authorized to fire substitute teachers... - Bart Simpson on chalkboard, _The Simpsons_ Derek R. Price writes: > > You saw the diff.c/diff.h error then? I just checked in a fix for that. Yep, that seems to hav

Re: Default postscript cleans miss *.cps & *.fns.

Akim Demaille wrote: > hi Derek, Hi. :) > Could you `grep indexcode' your texi sources? Thanks! [dprice@empress doc]$ fgrep indexcode cvs.texinfo [dprice@empress doc]$ Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED]

Default postscript cleans miss *.cps & *.fns.

Building postscript docs from *.texi sources using the default automake targets, the dev version of CVS produces cvs.cps & cvs.fns files as side effects. These files aren't removed by 'make clean' and thus break a distcheck. Derek -- Derek Price CVS Solutions Architect ( ht

Re: yaccvpath.test

Alexandre Oliva wrote: > On Feb 28, 2001, "Derek R. Price" <[EMAIL PROTECTED]> wrote: > > > CVS uses a single second sleep to guarentee timestamps change cross-platform > > IIRC, FAT filesystems can only store even second numbers. So, in > order to be

Re: yaccvpath.test

Pavel Roskin wrote: > Some unices (including GNU/Linux) are not very precise with respect to the > timestamps. It's likely that parse.c and the new parse.y are created in > the same second, so parse.c will appear to be up-to-date. Adding "sleep > 3" (I have no idea what would be a minimal safe t

Re: Current problems

Akim Demaille wrote: > "Derek R. Price" <[EMAIL PROTECTED]> writes: > > > Only a global is going to be seen within a separate function... > > Right, but `my' at the top level is a global. The problem was really > related to the specific semantics

Re: Current problems

Akim Demaille wrote: > # Now do all the work on each file. > foreach my $am_file (@input_files) > { > if (! -f ($am_file . '.am')) > { > &am_error ("\`" . $am_file . ".am' does not exist"); > } > else > { > &generate_makefile ($output_files{$am_file}, $am_file)

Re: subdirs.am and $(RECURSIVE_TARGETS)

Tom Tromey wrote: > > "Akim" == akim <[EMAIL PROTECTED]> writes: > > Akim> I wonder why we have a hard coded list list this in subdirs.am: > Akim> [ ... -recursive targets ... ] > > Historical reasons only, ie, I never thought of it. > > Akim> Not only to I find this more pleasant, but most

Re: PATCH: patsubst support

Tom Tromey wrote: > if FOO > var = a b > endif > derived = $(var:%=%.c) > if BAR > var = c d > endif Isn't the order irrelevant here since derived won't be evaluated until it's used? Um, the gmake manual calls this "expanded when read, except for the shell commands i

Re: 57-my-last-mying-changes.patch

Tom Tromey wrote: > > "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes: > > Akim> Six, six for them! (I'm not counting those for file handles, > Akim> which perl refuses as my, not sure to understand why). > > The way file handles work is another reason to dislike Perl. At > least, I've al

Redundant PACKAGE & VERSION set in test suite?

Is there a good reason that the following constructs occasionally appear in 'configure.in's as created by the test suite? AM_INIT_AUTOMAKE(nonesuch, nonesuch) PACKAGE=nonesuch VERSION=nonesuch Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) m

Re: Testsuite fails

Akim Demaille wrote: > Pavel Roskin <[EMAIL PROTECTED]> writes: > > > We probably need a special macro, e.g. AC_REQUIRE_FILE, so that the > > macros will be able to indicate what files they need. > > This is what Derek and I are working on :) But I doubt 2.50 will be > the good starting point,

Re: Testsuite fails

Tom Tromey wrote: > I imagine we'll have to radically revamp the test suite when we move > to using autoconf's tracing feature. The current test suite is very > dumb and doesn't usually generate a correct configure.in. I'm working on this so I can test my conversion. I've been reading the puro

Re: tests & graceful tool dependencies

"Derek R. Price" wrote: > test='eval exit 77 && dummy' Whoops. Excuse me. That works in every case except ($test). The subshell created by parens breaks things. I guess that isn't all that robust. Derek -- Derek Price CVS Solu

Re: tests & graceful tool dependencies

"Derek R. Price" wrote: > "Derek R. Price" wrote: > > > AUTOCONF='exit 77 &&' > > Excuse me: > > AUTOCONF='exit 77 && dummy' > > to keep the parser eternally happy. Or almost eternally happy.

Re: tests & graceful tool dependencies

"Derek R. Price" wrote: > AUTOCONF='exit 77 &&' Excuse me: AUTOCONF='exit 77 && dummy' to keep the parser eternally happy. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL

tests & graceful tool dependencies

>From tests/defs: # User can set which tools from Autoconf to use. test -z "$AUTOCONF" && AUTOCONF=autoconf if ($AUTOCONF --version) >/dev/null 2>&1; then has_autoconf=: needs_autoconf=: else has_autoconf=false needs_autoconf='exit 77' fi Wha

Re: Optimizing Makefiles

Akim Demaille wrote: > What is the general policy wrt `optimizations' in automake vs leaving > some job to make? For instance there are many places with code like: > > if ($relative_dir eq '.') > { > push (@files, 'acconfig.h'); >

Re: AC_CANONICAL_* && *_triplet

Tom Tromey wrote: > >>>>> "Derek" == Derek R Price <[EMAIL PROTECTED]> writes: > > Derek> Is there a good reason that Automake renames the three > Derek> variables set by AC_CANONICAL_* ('build', 'host', &

Re: AC_CANONICAL_*

Pavel Roskin wrote: > Hello, Derek! > > On Fri, 9 Feb 2001, Derek R. Price wrote: > > > Why do the AC_CANONICAL_* functions no longer set *_alias? There's a > > "cvs annotate" and "cvs log" are your friends. Akim did it. But the log > mes

Re: Patch 3 of 4: Avoid 8+3 filename trouble

Tom Tromey wrote: > > "Tim" == Tim Van Holder <[EMAIL PROTECTED]> writes: > > Tim> 2001-02-10 Tim Van Holder <[EMAIL PROTECTED]> > > Tim>* remake-hdr.am (@STAMP@): Use .T as suffix for the > Tim>temporary file. > > I don't think this is sufficient. I think you also have to change >

Re: Small autoreconf patch

Tim Van Holder wrote: > >> >* remake-hdr.am (@STAMP@): Use .T as suffix for the > >> >temporary file. > >> > >> You should probably patch autoconf's autoreconf too. > > > > > What part would need patching? > > > > The one that choose stamp file names like those created by automake. > > Ri

removing $seen_canonical

I've removed the references to $seen_canonical, re one of the FIXME comments on the way to enabling traces. I know this patch is kinda largish, but even if it doesn't get checked in yet, I'd like some feedback. This is somewhat integral to my work on traces. Derek -- Derek Price

AC_CANONICAL_* && *_triplet

Is there a good reason that Automake renames the three variables set by AC_CANONICAL_* ('build', 'host', & 'target') to 'build_triplet', 'host_triplet', & 'target_triplet'? Because using the current traces design, 'build', 'host', & 'target' would be substituted automatically, allowing removal/si

AC_CANONICAL_*

Why do the AC_CANONICAL_* functions no longer set *_alias? There's a FIXME comment and fixing it would be a matter of removing the 'dnl', as far as I can see and the CVS Automake is still expecting *_alias to be set: # _AC_CANONICAL_SPLIT(THING) # -- # Generate the variab

AM_INIT_AUTOMAKE support for 2.49d AC_INIT

Backwards compatible support for the new AC_INIT. ChangeLog entry: * m4/init.m4 (AM_INIT_AUTOMAKE): If AC_PACKAGE_NAME & AC_PACKAGE_VERSION are set, use those to set PACKAGE & VERSION in lieu of arguments. Derek -- Derek Price CVS Solutions Architect ( http://CVSHo

Re: DIST_COMMON broke

Tom Tromey wrote: > >>>>> "Derek" == Derek R Price <[EMAIL PROTECTED]> writes: > > Derek> Also, looking at this area of the code reminds me that I sent > Derek> a, unfortunately largish, patch in something over a month ago > Derek> th

Re: DIST_COMMON broke

Tom Tromey wrote: > >>>>> "Derek" == Derek R Price <[EMAIL PROTECTED]> writes: > > Derek> Also, looking at this area of the code reminds me that I sent > Derek> a, unfortunately largish, patch in something over a month ago > Derek> th

Re: tests/ChangeLog

Pavel Roskin wrote: > On 7 Feb 2001, Tom Tromey wrote: > > > I've long considered it a mistake that tests/ChangeLog exists. I > > think it should be merged with the main ChangeLog. > > > > How about I rename tests/ChangeLog and we start putting entries into > > the toplevel ChangeLog? Any objec

Re: DIST_COMMON broke

"Derek R. Price" wrote: > Tom Tromey wrote: > > > Derek> Checked in? Fixes? I'm not pulling any changes... > > > > I can't explain that. I've seen the commit message and everything. > > > > You aren't using the subversions

Re: DIST_COMMON broke

Tom Tromey wrote: > Derek> Checked in? Fixes? I'm not pulling any changes... > > I can't explain that. I've seen the commit message and everything. > > You aren't using the subversions automake are you? > That is a mirror that doesn't update. Yeah, I am. Where is the other one? Derek -- De

Re: DIST_COMMON broke

Tom Tromey wrote: > > "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes: > > >> I'm checking this in. > > Pavel> I'm sorry, but the bug seems to be yours. The new test fails > Pavel> after automake.in changes from revision 1.848 to 1.849. > > Oh, I know it is mine.. > > Pavel> In fact it say

Re: DIST_COMMON broke

Tom Tromey wrote: > Anyway I wrote a test for the weird case and checked it in. > > I also checked in a fix for both the recent bugs in that area. I'm > afraid I'm not entirely sure why my fix fixes distcommon.test :-(. Checked in? Fixes? I'm not pulling any changes... Derek -- Derek Price

Re: DIST_COMMON broke

Pavel Roskin wrote: > The new test fails exactly how it should. I'm going to apply it unless you > come with something better. Well, you should have seen my slightly more succinct version by now. I'd say check them both in, as there is some logic that says it'd be nice to be able to notice the

Re: DIST_COMMON broke

Pavel Roskin wrote: > Hello, Derek! > > > > > Looks like someone broke the 'make dist' target in the last few days. > > I also noticed that. > > > > > Specifically, input files from AC_OUTPUT are no longer being added to > > > > DIST_COMMON... > > Exactly the same problem. > > > > Here's the patc

Re: DIST_COMMON broke

"Derek R. Price" wrote: > "Derek R. Price" wrote: > > > Looks like someone broke the 'make dist' target in the last few days. > > Specifically, input files from AC_OUTPUT are no longer being added to > > DIST_COMMON... > > Here's t

Re: DIST_COMMON broke

"Derek R. Price" wrote: > Looks like someone broke the 'make dist' target in the last few days. > Specifically, input files from AC_OUTPUT are no longer being added to > DIST_COMMON... Here's the patch. Derek -- Derek Price CVS Soluti

Re: AM_CONFIG_HEADER & stamp-h files edition 3

"Derek R. Price" wrote: > Inspired by Akim Demaille's use of ifdef, I wrote a third edition of > this patch which increases functionality when used with a current > Autoconf. I just wanted to let you all know that. ... Ok, fine, here's the patc

AM_CONFIG_HEADER & stamp-h files edition 3

Inspired by Akim Demaille's use of ifdef, I wrote a third edition of this patch which increases functionality when used with a current Autoconf. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.co

Bug + patch

Somebody checked in a bad quote recently. It breaks at least the stamph/header targets. Patch attached. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- 82. Hold a hard drive to your ea

Re: amtraces

"Derek R. Price" wrote: > > > +# This macro handles several different things. > > > +AM_INIT_AUTOMAKE => > > > + sub { $seen_make_set = $_[0]; > > > + $seen_arg_prog = $_[0]; > > > + $seen_prog_

Re: 31-ac-libsources.patch & Re: amtraces

Akim Demaille wrote: > FYI, I applied this to Autoconf: > > 2001-02-03 Akim Demaille <[EMAIL PROTECTED]> > > * acfunctions.m4 (AC_FUNC_ERROR_AT_LINE, AC_FUNC_ONSTACK): Use > AC_LIBSOURCES. > > 2001-02-03 Akim Demaille <[EMAIL PROTECTED]> > > * acgeneral.m4 (AC_LIBOBJ_D

Re: amtraces

Akim Demaille wrote: > "Derek R. Price" <[EMAIL PROTECTED]> writes: > > All these comments are related to the same idea: Automake must know as > less as possible about macros. It means that if needed, we have to > > ~/src/ace % echo "AC_INIT AC_CANONICAL_

Re: amtraces

"Derek R. Price" wrote: > Tom Tromey wrote: > > > >>>>> "Derek" == Derek R Price <[EMAIL PROTECTED]> writes: > > > > Derek> From comp-vars.am: > > Derek> DEFS = @DEFS@@DEFAULT_INCLUDES@ > > > > Ok, thanks.

Re: amtraces

Tom Tromey wrote: > >>>>> "Derek" == Derek R Price <[EMAIL PROTECTED]> writes: > > Derek> From comp-vars.am: > Derek> DEFS = @DEFS@@DEFAULT_INCLUDES@ > > Derek> Automake subs some compiler include paths into > Derek> @DE

Re: amtraces

"Derek R. Price" wrote: > [EMAIL PROTECTED] wrote: > > > On Fri, Feb 02, 2001 at 01:17:13PM -0500, Derek R. Price wrote: > > > Akim Demaille wrote: > > > that I certainly would like to toy with your implementation, I'd vote > > > for an inclu

Re: amtraces

[EMAIL PROTECTED] wrote: > On Fri, Feb 02, 2001 at 01:17:13PM -0500, Derek R. Price wrote: > > Akim Demaille wrote: > > > > > "Derek R. Price" <[EMAIL PROTECTED]> writes: > > > > Patch against the current CVS Automake attached. Please excuse

Re: amtraces

Akim Demaille wrote: > "Derek R. Price" <[EMAIL PROTECTED]> writes: > > > Ok, I have amtraces code that slurps in almost all the information that > > scan_one_autoconf_file used to. Unfortuantely I hit a minor snag: > > We are probably working on the

amtraces

Ok, I have amtraces code that slurps in almost all the information that scan_one_autoconf_file used to. Unfortuantely I hit a minor snag: Since _all_ AC_SUBSTs are being processed now, at least one instance where Automake was allowing for user override is now broken. The case in question is the

Re: Perl Bug?

"Derek R. Price" wrote: > [EMAIL PROTECTED] wrote: > > > But in the very same function, if I use $_ instead of @_, which is > > what the following line does: > > $_ isn't set upon function entry in perl. Only @_. The value of your $_ is left >over f

Re: Perl Bug?

[EMAIL PROTECTED] wrote: > But in the very same function, if I use $_ instead of @_, which is > what the following line does: $_ isn't set upon function entry in perl. Only @_. The value of your $_ is left over from somewhere. By the way, I think I have amtraces 99% working. Are we going to

Re: patch: stamp-h? files in subdirs

Tom Tromey wrote: > >>>>> "Derek" == Derek R Price <[EMAIL PROTECTED]> writes: > > Derek> by an automake configure script. The problem was in > Derek> AM_CONFIG_HEADERS. I fixed it, but is dependent on the > Derek> autoconf beta. > &g

Re: patch: stamp-h? files in subdirs

Tim Van Holder wrote: > >(_AM_DIRNAME): helper function which basically implements an sh > >`dirname` in m4 > Only have 1 problem with it: no support for DOS-style paths (and this is > conveniently not tested in your dirname.test either :-P). Yeah, sorry. I noticed that, but I d

amtraces functionality

The amtraces functionality for AC_CONFIG_FILES is totally broken. Anyone mind if I spend a few minutes on it? Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- I don't suffer from stress.

Re: patch: stamp-h? files in subdirs

"Derek R. Price" wrote: > stamp-h? files in subdirs are still being created in the wrong locations > by an automake configure script. The problem was in AM_CONFIG_HEADERS. > I fixed it, but is dependent on the autoconf beta. Patch attached. > > I was thinking of at

patch: stamp-h? files in subdirs

stamp-h? files in subdirs are still being created in the wrong locations by an automake configure script. The problem was in AM_CONFIG_HEADERS. I fixed it, but is dependent on the autoconf beta. Patch attached. I was thinking of attempting to eliminate the need for the recreation of stamp-h? fi

Re: 10-check-am.patch

Akim Demaille wrote: > | It is fine to `cvs add' a file so that `cvs diff -N' creates the > | correct diff. This applies generally -- if you don't have cvs write > | access there is a script you can get that will do a phony `cvs add' by > | manipulating CVS/Entries. > > Oh, I didn't know that, t

stamp files

Why do automake stamp targets go through all the trouble of creating a temporary stamp file before executing config.status and then moving the stamp file into the correct position? thirdfile.h: stamp-h3 @if test ! -f $@; then \ rm -f stamp-h3; \

Re: More an autopackage

Michael Sweet wrote: > Rusty Ballinger wrote: > > ... > > (What packaging systems only let you create packages as root, and > > why do they do that? I know rpm *wants* you to be root, but you > > don't have to be...) > > Debian's dpkg needs you to run as root; otherwise the files you > install w

Re: More an autopackage

Harlan Stenn wrote: > Are there several issues here? > > The package maintainer has the package to worry about. Aha! Here's the crossed wire. What I was envisioning was a package tool designed such that most platforms wouldn't _need_ devoted package maintainers. A single package maintainer usi

Re: More an autopackage

Geoffrey Wossum wrote: > > You can use GNU m4 or PERL in autoconf and automake, as these are > > maintainer-only tools. If autopackage is a package-installer tool (i.e. a > > native package front-end) the choice of implementation language is almost > > restricted to "/bin/sh" or "/bin/sh" and pro

Re: VPATH elimination by configure

"Derek R. Price" wrote: > Akim Demaille wrote: > > > VPATH is just set to srcdir? So then, I'm in favor of Derek's patch > > which seems finer that the current one, and updating the Autoconf > > documentation to explain exactly what happens. > >

Re: VPATH elimination by configure

Akim Demaille wrote: > So, I think I'm slowly starting to understand this VPATH stuff: > configure wants to remove it only when useless, right? I.e., when > VPATH is just set to srcdir? So then, I'm in favor of Derek's patch > which seems finer that the current one, and updating the Autoconf >

Re: More an autopackage

Tom Tromey wrote: > Unfortunately, I don't think it is that easy. > > First, Makefile.am contents can be conditional on the particular > configuration. That is why you really want to deal with the > post-configuration package (using `make') and not Makefile.am. > > Second, the more complex post-

Re: More an autopackage

Geoffrey Wossum wrote: > I was thinking about this, and I considered another possibility. autopkg > would scan the Makefile.am to build a basic specfile, which the developer > could then add pre/post install scripts and so forth. This would be > analogous to autoscan producing a basic configure

Re: Package support (RPM, deb, pkg, kits, etc.)

Tom Tromey wrote: > The idea behind DOCUMENTATION is to provide a way to install README > and the other stuff that ends up (eg) in /usr/doc/$PACKAGE. Just a note, I believe the RedHat standard is /usr/share/doc now. Derek -- Derek Price CVS Solutions Architect ( http://CVS

Another problem with BSD Make

It seems some BSD makes don't look through VPATH for targets either (i.e. when they're not found in $(builddir) make assumes they are missing and rebuilds). Mostly this isn't a problem, but there are a few cases where it is. For example, info targets are rebuilt every time and I can't create a *

Re: bug: depcomp misplaced

"Derek R. Price" wrote: > Okay, I fixed this as well as all the special casing of '.' that the code is > littered with FIXME comments about. I've included ChangeLog entries in the patch > as well as a new test case, but here's a bit more detail: Is

[PATCH] Another BSD make incompatibility

Found another bug in automake's support for dependencies using BSD's make. This one is based on the fact that BSD make doesn't allow comments to continue on the next line using '\'. I just hooked into the existing conditional machinery instead of stuffing "\@AMDEP\@" as the first item in the DEP

[Fwd: Ultrix problem]

Whoops. Missed a list. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- He who laughs last thinks slowest. Harlan Stenn wrote: > /bin/sh: : not found > WARNING: `:' is needed, an

Re: BSD make and dependencies

Tom Tromey wrote:Derek> Apparently BSD wants something like the following: > Derek> .include "file" > Derek> or > Derek> .include > > Yuck. Does make have -I options too? Don't know. I didn't actually have a BSD box until last week and I haven't touched it over the last few days. I'l

Re: distributing files generated by configure

"Derek R. Price" wrote: > Raja R Harinath wrote: > > > BTW, why do you need to 'configure' or 'sed' substitute a version > > number into a .c file -- you already have config.h which defines the > > symbol 'VERSION' to the version

Re: distributing files generated by configure

Raja R Harinath wrote: > BTW, why do you need to 'configure' or 'sed' substitute a version > number into a .c file -- you already have config.h which defines the > symbol 'VERSION' to the version number string. That's a good point. They're there because I just converted this source to use Autom

Re: [Fwd: --add-missing]

Tom Tromey wrote: > I wouldn't be averse to adding a `pdf' target so that `make pdf' works > as expected. Someone else would have to write it though since I don't > know how. It should be the exact target used for DVI except for the addition of a '--pdf' switch to the texi2dvi command line. I'

BSD make and dependencies

Is there any support in Automake for BSD make's style of includes? Apparently BSD wants something like the following: .include "file" or .include Where "" and <> have similiar meanings to what they would have in a C program include. Derek -- Derek Price CVS Solu

distributing files generated by configure

I have several files which are generated by configure that I want three things to happen to. 1) Created in $(srcdir) rather than $(builddir) or, alternately and second best, targets added which make the $(srcdir) counterparts dependent on the $(builddir) versions. I don't like option 2 because a

distclean-generic bug

The distclean-generic target is removing the following files: stamp-h stamp-h[0-9]* The listing of 'stamp-h[0-9]*' causes 'stamp-h[0-9].in' files to be removed incorrectly. And incidentally, it would be unecessary to list stamp-h if you applied the stamp-h fix I sent to the list sometime in

Re: [PATCH] etags support

Tom Tromey wrote: > >>>>> "Derek" == Derek R Price <[EMAIL PROTECTED]> writes: > > Hmm. I'm running RH 6.2 and /usr/bin/etags is the GNU version: I just looked into it and it looks like etags was distributed with the version of emacs (20.5) t

Re: New version of RPMs

"Derek R. Price" wrote: > "Derek R. Price" wrote: > > > I added the etags support to my RPMs: > > I regenerated them again using todays version of the CVS Automake since the > failing vtexi.test wasn't a bug. And one more try. etags.m4 wasn

Re: [PATCH] etags support

"Derek R. Price" wrote: > > > I added a macro to test for the presence of etags and whether it > > > supports "--etags-include=" or "-i " for includes. Okay, one more try. I hadn't added etags.m4 to the Makefile.am so it wasn't being in

Re: [PATCH] etags support

Raja R Harinath wrote: > > I added a macro to test for the presence of etags and whether it > > supports "--etags-include=" or "-i " for includes. > > If Exuberent etags is supposed to be a drop-in replacement for Emacs > etags, it should support the same options. Otherwise, it is a bug in > the

Re: New version of RPMs

"Derek R. Price" wrote: > I added the etags support to my RPMs: I regenerated them again using todays version of the CVS Automake since the failing vtexi.test wasn't a bug. http://alumni.engin.umich.edu/~oberon/automake-1.4a-0_CVSHome_org_6.noarch.rpm http://alumni.engin

[PATCH] Re: vtexi.test failing

"Derek R. Price" wrote: > "Derek R. Price" wrote: > > > vtexi.test is failing in the CVS automake. I assume it broke due to the > > recent vtexi behavior change. > > I just looked and I was right. The fix was simple - the test simply wasn't

Re: vtexi.test failing

"Derek R. Price" wrote: > vtexi.test is failing in the CVS automake. I assume it broke due to the > recent vtexi behavior change. I just looked and I was right. The fix was simple - the test simply wasn't expecting the $(srcdir)/ prefix on version.texi.

New version of RPMs

I added the etags support to my RPMs: http://alumni.engin.umich.edu/~oberon/automake-1.4a-0_CVSHome_org_5.src.rpm http://alumni.engin.umich.edu/~oberon/automake-1.4a-0_CVSHome_org_5.src.rpm Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL

  1   2   >