Re: More an autopackage

2001-01-18 Thread Ganesan Rajagopal
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

Re: More an autopackage

2001-01-18 Thread Tom Tromey
> "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

Re: More an autopackage

2001-01-18 Thread Tom Tromey
> "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.

Re: Support for configure.ac

2001-01-18 Thread Tom Tromey
> "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

Re: More an autopackage

2001-01-18 Thread Bob Friesenhahn
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

Re: More an autopackage

2001-01-18 Thread Geoffrey Wossum
> > 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?

Re: More an autopackage

2001-01-18 Thread Rusty Ballinger
> > 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

Re: More an autopackage

2001-01-18 Thread Alexandre Oliva
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

Re: More an autopackage

2001-01-18 Thread David Lee
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,

Re: OS-sympathetic installation

2001-01-18 Thread Geoffrey Wossum
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!). >

More an autopackage

2001-01-18 Thread Geoffrey Wossum
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

Re: make install-strip in cross-compilation environments

2001-01-18 Thread Alexandre Oliva
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

Re: make install-strip in cross-compilation environments

2001-01-18 Thread Tom Tromey
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

OS-sympathetic installation

2001-01-18 Thread David Lee
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

Re: Support for configure.ac

2001-01-18 Thread Lars Hecking
[...] > 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;',

Re: Support for configure.ac

2001-01-18 Thread Akim Demaille
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 =

Re: Support for configure.ac

2001-01-18 Thread Akim Demaille
| 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

Re: Support for configure.ac

2001-01-18 Thread Lars Hecking
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.

Re: Support for configure.ac

2001-01-18 Thread Raja R Harinath
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

Re: Support for configure.ac

2001-01-18 Thread Akim Demaille
~/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

Re: Support for configure.ac

2001-01-18 Thread Lars Hecking
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 . && /

Re: Support for configure.ac

2001-01-18 Thread Akim Demaille
> "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

Re: Support for configure.ac

2001-01-18 Thread Lars Hecking
> 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

Re: Support for configure.ac

2001-01-18 Thread Akim Demaille
$ 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

Re: Support for configure.ac

2001-01-18 Thread Lars Hecking
> 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

Re: Support for configure.ac

2001-01-18 Thread Akim Demaille
| > | 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

Re: Support for configure.ac

2001-01-18 Thread Lars Hecking
> | 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

Re: unquote-am_config_header.patch

2001-01-18 Thread Lars J. Aas
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

Re: Support for configure.ac

2001-01-18 Thread Akim Demaille
| > 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

Re: Support for configure.ac

2001-01-18 Thread Lars Hecking
> 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

Re: make install-strip in cross-compilation environments

2001-01-18 Thread Alexandre Oliva
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

Re: Support for configure.ac

2001-01-18 Thread Akim Demaille
> "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

Re: Support for configure.ac

2001-01-18 Thread Lars Hecking
> 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 >

Re: Support for configure.ac

2001-01-18 Thread Akim Demaille
> "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

Re: make install-strip in cross-compilation environments

2001-01-18 Thread Alexandre Duret-Lutz
>>> "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

unquote-am_config_header.patch

2001-01-18 Thread Alexandre Duret-Lutz
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