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
> "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
> "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.
> "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
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
> > 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?
> > 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
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
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,
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!).
>
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
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
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
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
[...]
> 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;',
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
=
| 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
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.
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
~/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
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 . && /
> "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
> 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
$ 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
> 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
| > | 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
> | 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
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
| > 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
> 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
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
> "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
> 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> 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
>>> "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
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
36 matches
Mail list logo
