Hi,
I'm afraid this
AM_CONFIG_HEADER([config.h])
leads to
configure.in: 3: required file `./[config.h].in' not found
May I suggest the change below? (I browsed the source and
didn't find something similar to unquote_m4_arg, that's quite
surprising; did I missed something?)
2001-01-17
>>> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes:
> "adl" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes:
[...]
adl> b) change the Makefiles to not call `install -s', but just
adl> `install' followed by a direct call to the correct strip.
Tom> This would make sense. It is unfortu
> "Lars" == Lars Hecking <[EMAIL PROTECTED]> writes:
Lars> I posted everything I did. I did not install automake, only ran
Lars> configure and make dist straight from a copy of my checked-out
Lars> tree.
Well, I don't know.
~/src/am % ./configure
loading cache ./config.cache
checking for a
> But your output, compared to mine, contains:
>
> $ make dist
> cd . && /tmp/automake/aclocal --acdir=m4
> cd . && /tmp/automake/automake --amdir=. --gnits Makefile
> cd . && /bin/sh /tmp/automake/missing --run autoconf
>
> i.e., your files are not up to date. Try from a freshly checked out
>
> "Lars" == Lars Hecking <[EMAIL PROTECTED]> writes:
Lars> Undoubtedly, automake-cvs running on its own files should
Lars> produce something useful, shouldn't it?
Yes, indeed. But I just switched me brains on, and understood.
Sure you have the new .am files, but since the Makefile want to
On Jan 17, 2001, Tom Tromey <[EMAIL PROTECTED]> wrote:
adl> b) change the Makefiles to not call `install -s', but just
adl> `install' followed by a direct call to the correct strip.
> This would make sense. It is unfortunate though.
We could surely adjust install-sh so as to take a STRIP vari
> Yes, indeed. But I just switched me brains on, and understood.
>
> Sure you have the new .am files, but since the Makefile want to update
> the Makefiles first, you run an old automake which does not, indeed,
> substitute @CONFIGURE_AC@. So find a means, but you have to `make
> automake' bef
| > Yes, indeed. But I just switched me brains on, and understood.
| >
| > Sure you have the new .am files, but since the Makefile want to update
| > the Makefiles first, you run an old automake which does not, indeed,
| > substitute @CONFIGURE_AC@. So find a means, but you have to `make
| > a
On Thu, Jan 18, 2001 at 09:35:44AM +0100, Alexandre Duret-Lutz wrote:
: Hi,
:
: I'm afraid this
:
: AM_CONFIG_HEADER([config.h])
:
: leads to
:
: configure.in: 3: required file `./[config.h].in' not found
You will also find that
AC_CONFIG_AUX_DIR([cfg])
won't fly according to automake
> | At no time an old copy of automake is run.
>
> You don't seem to understand. Make a
>
> diff automake.in automake
>
> and I think you'll see what I mean.
% grep @CONFIGURE_AC@ Makefile.in
$(srcdir)/stamp-vti: automake.texi $(top_srcdir)/@CONFIGURE_AC@
%
If autoconf, not automake is r
| > | At no time an old copy of automake is run.
| >
| > You don't seem to understand. Make a
| >
| > diff automake.in automake
| >
| > and I think you'll see what I mean.
|
| % grep @CONFIGURE_AC@ Makefile.in
| $(srcdir)/stamp-vti: automake.texi $(top_srcdir)/@CONFIGURE_AC@
| %
|
| If a
> Could you please run
>
> diff automake.in automake
>
> and see if it helps you understanding what I'm trying to say? I agree
> I'm not clear, and I believe the diff will be much clearer than I am.
$ diff -u automake.in automake
--- automake.in Wed Jan 17 06:30:29 2001
+++ automake
$ diff -u automake.in automake
--- automake.in Wed Jan 17 06:30:29 2001
+++ automakeThu Jan 18 13:46:25 2001
According to the headers of your mails, somehow, automake finally got
created (the last failure you presented was at X-From-Line:
[EMAIL PROTECTED] Thu Jan 18 13:06:26 2001). So, if
> According to the headers of your mails, somehow, automake finally got
> created (the last failure you presented was at X-From-Line:
> [EMAIL PROTECTED] Thu Jan 18 13:06:26 2001). So, if indeed you have:
In all cases I posted, automake _did_ get created.
> ~/src/am % grep CONFIGURE_AC autom
> "Lars" == Lars Hecking <[EMAIL PROTECTED]> writes:
Lars> I have that, but it still doesn't work.
What did you type? How did it fail? Do your Makefile.in still have
the @CONFIGURE_AC@ stuff? If so, run `touch *.am; make'.
Lars> My idea is that this new feature in automake is not compat
Akim Demaille writes:
> > "Lars" == Lars Hecking <[EMAIL PROTECTED]> writes:
>
> Lars> I have that, but it still doesn't work.
>
> What did you type? How did it fail? Do your Makefile.in still have
> the @CONFIGURE_AC@ stuff? If so, run `touch *.am; make'.
$ touch *.am
$ make
cd . && /
~/src/am % perl --versionnostromo 17:58
This is perl, v5.6.0 built for i386-linux
Copyright 1987-2000, Larry Wall
Perl may be copied only under the terms of either the Artistic License or the
GNU General Public License, which may be found in the Perl 5.0
Lars Hecking <[EMAIL PROTECTED]> writes:
> > | At no time an old copy of automake is run.
> >
> > You don't seem to understand. Make a
> >
> > diff automake.in automake
> >
> > and I think you'll see what I mean.
>
> % grep @CONFIGURE_AC@ Makefile.in
> $(srcdir)/stamp-vti: automake.texi $(t
Akim Demaille writes:
> ~/src/am % perl --versionnostromo 17:58
>
> This is perl, v5.6.0 built for i386-linux
[...]
> What do you have?
Tried both 5.005_03 and 5.6.0 built for sun4-solaris. It makes no difference.
| I see this even with an installed automake. It appears that
| 'texi-vers.am' doesn't have the CONFIGURE_AC transform before being
| inserted into Makefile.in. From automake.in, in &handle_texinfo,
| around line 2277
|
| $output_rules .=
| &file_contents_with_trans
Once the `make check' finished, I'll check this in:
Index: ChangeLog
from Akim Demaille <[EMAIL PROTECTED]>
* automake.in (handle_texinfo): Use &transform, and transform
CONFIGURE_AC.
Reported by Lars Hecking, and diagnosed by Raja R Harinath.
Index: automake.in
=
[...]
> Now I have it. Sorry Lars... The test suite did not see anything...
> I'm fixing this.
I have added
. 's/\@VTEXI\@/' . $vtexi . '/g;'
+. 's/\@CONFIGURE_AC\@/' . $configure_ac . '/g;'
. 's,\@MDDIR\@,' . $conf_pat . ',g;',
I'll instantly admit that I have very little experience of automake
(although a reasonable amount of autoconf), so my question may be way
off-beam. Anyway...
Over the years, the "standardisation" of many packages, GNU and non-GNU,
onto the autoconf mechanism has vastly eased my life as an instal
Alexandre> We could surely adjust install-sh so as to take a STRIP
Alexandre> variable into account, and set INSTALL_STRIP (a new
Alexandre> variable, set to the same as `$(INSTALL)' if not
Alexandre> cross-compiling, or to `STRIP=toolchain-strip
Alexandre> $(CONFIG_SHELL) /path/to/install-sh' oth
On Jan 18, 2001, Tom Tromey <[EMAIL PROTECTED]> wrote:
Alexandre> We could surely adjust install-sh so as to take a STRIP
Alexandre> variable into account, and set INSTALL_STRIP (a new
Alexandre> variable, set to the same as `$(INSTALL)' if not
Alexandre> cross-compiling, or to `STRIP=toolchain-s
Hi again,
I want to work on the unified front-end to native packaging systems like I
posted before, but the bossman doesn't want to wait until that's useable.
So the autopackage front-end is going to be YASP (yet another side
project) for me.
Anyway, here's some of my thoughts about it:
1) writt
David,
> But there seems to be one vital missing component. Way back in the olden
> days, we needed "make install" to put the product into its final
> location(s). But these days, many operating systems have their own
> package-management mechanisms (the word "package" is here overloaded!).
>
On Thu, 18 Jan 2001, Geoffrey Wossum wrote:
> I want to work on the unified front-end to native packaging systems like I
> posted before, but the bossman doesn't want to wait until that's useable.
> So the autopackage front-end is going to be YASP (yet another side
> project) for me.
>
> Anyway,
On Jan 18, 2001, David Lee <[EMAIL PROTECTED]> wrote:
> On Thu, 18 Jan 2001, Geoffrey Wossum wrote:
>> 1) written in Python
> Wouldn't Perl5 be a more widely acceptable choice? Considerably so?
> (Indeed, isn't automake already in Perl? Why choose something different?
> Especially when tha
> > Wouldn't Perl5 be a more widely acceptable choice? Considerably so?
> > (Indeed, isn't automake already in Perl? Why choose something different?
> > Especially when that something is considerably less widely installed?)
>
> Because Perl is almost unreadable and Python is a very nice language
> > Anyway, here's some of my thoughts about it:
> > 1) written in Python
>
> Wouldn't Perl5 be a more widely acceptable choice? Considerably so?
> (Indeed, isn't automake already in Perl? Why choose something different?
> Especially when that something is considerably less widely installed?
On Thu, 18 Jan 2001, Geoffrey Wossum wrote:
> > > Anyway, here's some of my thoughts about it:
> > > 1) written in Python
> >
> > Wouldn't Perl5 be a more widely acceptable choice? Considerably so?
> > (Indeed, isn't automake already in Perl? Why choose something different?
> > Especially w
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> Once the `make check' finished, I'll check this in:
Did the bug affect any of the existing test cases?
If not I generally add a new test.
Tom
> "Bob" == Bob Friesenhahn <[EMAIL PROTECTED]> writes:
Bob> Aren't we supposed to use GNU guile for all FSF-supported
Bob> script-based tools? In fact, isn't Automake itself intended to be
Bob> eventually re-written in guile?
Yes, that is the intent. I doubt I'll be doing the work though.
> "Geoffrey" == Geoffrey Wossum <[EMAIL PROTECTED]> writes:
Geoffrey> Anyway, here's some of my thoughts about it:
Geoffrey> 1) written in Python
The required language flame war has already started. However I think
the implementation language is the least important thing. The
important th
Has anybody looked at (epm) Easy Package Manager (http://www.easysw.com/epm/?
>From the FAQ:
--
It is a simple tool that generates software and patch distributions in
various formats, including:
AT&T Software Packages ("pkg"), used by Solaris.
Debian Package Manager ("dpkg")
HP-UX Software Pac
36 matches
Mail list logo
