unquote-am_config_header.patch
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 Alexandre Duret-Lutz [EMAIL PROTECTED]
* automake.in (unquote_m4_arg): New function.
(scan_one_configure_file): Call unquote_m4_arg on
AM_CONFIG_HEADER argument, so that AM_CONFIG_HEADER([foobar.h])
works.
--- automake.in.old Wed Jan 17 20:13:19 2001
+++ automake.in Wed Jan 17 22:31:03 2001
@@ -4558,7 +4558,7 @@
$config_header_line = $.;
local ($one_hdr);
- foreach $one_hdr (split (' ', $2))
+ foreach $one_hdr (split (' ', unquote_m4_arg ($2)))
{
push (@config_fullnames, $one_hdr);
if ($one_hdr =~ /^([^:]+):(.+)$/)
@@ -7759,6 +7759,36 @@
{
local ($pat) = @_;
return ${pat};
+}
+
+# Remove one level of brackets and strip leading spaces,
+# as does m4 to function arguments.
+sub unquote_m4_arg
+{
+$_ = shift;
+s/^\s*//;
+
+my @letters = split //;
+my @result = ();
+my $depth = 0;
+
+foreach (@letters)
+{
+ if ($_ eq '[')
+ {
+ ++$depth;
+ next if $depth == 1;
+ }
+ elsif ($_ eq ']')
+ {
+ --$depth;
+ next if $depth == 0;
+ # don't count orphan right brackets
+ $depth = 0 if $depth 0;
+ }
+ push @result, $_;
+}
+return join '', @result;
}
--
Alexandre Duret-Lutz
Re: make install-strip in cross-compilation environments
"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 unfortunate though. Ok, I'll try to make that change this week-end (unless someone else want to do it). [...] -- Alexandre Duret-Lutz
Re: Support for configure.ac
"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 BSD compatible install... (cached) /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... (cached) mawk
checking whether make sets ${MAKE}... (cached) yes
checking for perl... (cached) /usr/bin/perl
creating ./config.status
creating Makefile
creating automake
creating aclocal
creating m4/Makefile
creating tests/Makefile
~/src/am % make dist nostromo 10:40
chmod -R a+w automake-1.4c /dev/null 21; rm -rf automake-1.4c
mkdir automake-1.4c
for subdir in . m4 tests; do \
if test "$subdir" = .; then :; else \
test -d automake-1.4c/$subdir \
|| mkdir automake-1.4c/$subdir \
|| exit 1; \
(cd $subdir make top_distdir=../automake-1.4c distdir=../automake-1.4c/$subdir
distdir) \
|| exit 1; \
fi; \
done
make[1]: Entre dans le rpertoire `/mnt/nostromo/home/lrde/prof/akim/src/am/m4'
make[1]: Quitte le rpertoire `/mnt/nostromo/home/lrde/prof/akim/src/am/m4'
make[1]: Entre dans le rpertoire `/mnt/nostromo/home/lrde/prof/akim/src/am/tests'
make[1]: Quitte le rpertoire `/mnt/nostromo/home/lrde/prof/akim/src/am/tests'
make top_distdir="automake-1.4c" distdir="automake-1.4c" dist-info
make[1]: Entre dans le rpertoire `/mnt/nostromo/home/lrde/prof/akim/src/am'
list='automake.info'; \
for base in $list; do \
d=.; \
for file in `CDPATH=: cd $d eval echo $base*`; do \
test -f automake-1.4c/$file \
|| cp -p $d/$file automake-1.4c/$file; \
done; \
done
make[1]: Quitte le rpertoire `/mnt/nostromo/home/lrde/prof/akim/src/am'
find automake-1.4c -type d ! -perm -777 -exec chmod a+rwx {} \; -o \
! -type d ! -perm -444 -links 1 -exec chmod a+r {} \; -o \
! -type d ! -perm -400 -exec chmod a+r {} \; -o \
! -type d ! -perm -444 -exec /bin/sh ./install-sh -c -m a+r {} {} \; \
|| chmod -R a+r automake-1.4c
/bin/sh /home/lrde/prof/akim/src/am/missing --run tar chof - automake-1.4c |
GZIP=--best gzip -c automake-1.4c.tar.gz
chmod -R a+w automake-1.4c /dev/null 21; rm -rf automake-1.4c
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
automake?
Re: Support for configure.ac
"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 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' before making the Makefiles. On your system automake.in is new, but not automake yet.
Re: Support for configure.ac
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' before making the Makefiles. On your system automake.in is new, but not automake yet. At no time an old copy of automake is run. $ pwd /tmp/automake $ ./configure [...] $ make automake cd . /tmp/automake/aclocal --acdir=m4 cd . /tmp/automake/automake --amdir=. --gnits Makefile ^^ cd . /bin/sh /tmp/automake/missing --run autoconf [...] $ make dist make: *** No rule to make target `@CONFIGURE_AC@', needed by `stamp-vti'. Stop. $
Re: Support for configure.ac
| 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' before making the Makefiles. On your system automake.in is | new, but not automake yet. | | 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.
Re: unquote-am_config_header.patch
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... Lars J -- Innovation is one percent inspiration and ninetynine percent perspiration, and in my case; twice that... -- Norville Barnes, `The Hudsucker Proxy'
Re: Support for configure.ac
| 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 responsible for substituting @CONFIGURE_AC@ in the Makefile, then this simply doesn't work with autoconf-2.13, only with autoconf-cvs.
Re: Support for configure.ac
| | 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 responsible for substituting @CONFIGURE_AC@ | in the Makefile, then this simply doesn't work with autoconf-2.13, only | with autoconf-cvs. 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.
Re: Support for configure.ac
$ 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 indeed you have:
~/src/am % grep CONFIGURE_AC automake
local ($xform) = transform ("CONFIGURE_AC" = $configure_ac);
$xform = transform ('CONFIGURE_AC' = $configure_ac,
then *now* `make' should work.
Re: Support for configure.ac
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 automake
local ($xform) = transform ("CONFIGURE_AC" = $configure_ac);
$xform = transform ('CONFIGURE_AC' = $configure_ac,
then *now* `make' should work.
I have that, but it still doesn't work. My idea is that this new feature
in automake is not compatible with released versions of autoconf. If it
were, it should show up in config.status.
$ grep CONFIGURE_AC config.status
$
Re: Support for configure.ac
"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 compatible Lars with released versions of autoconf. If it were, it should show Lars up in config.status. Lars $ grep CONFIGURE_AC config.status $ No, @CONFIGURE_AC@ is handled by automake, not related to configure or autoconf in anyway.
Re: Support for configure.ac
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 . /tmp/automake/automake --amdir=. --gnits Makefile
cd . \
CONFIG_FILES=Makefile CONFIG_HEADERS= /bin/sh ./config.status
creating Makefile
Making all in .
make[1]: Entering directory `/tmp/automake'
make[1]: *** No rule to make target `@CONFIGURE_AC@', needed by `stamp-vti'. Stop.
make[1]: Leaving directory `/tmp/automake'
make: *** [all-recursive] Error 1
$ grep CONFIGURE_AC automake
local ($xform) = transform ("CONFIGURE_AC" = $configure_ac);
$xform = transform ('CONFIGURE_AC' = $configure_ac,
No, @CONFIGURE_AC@ is handled by automake,
Apparently not, at least in my case :-(
Makefile.in from automake-cvs does not contain @CONFIGURE_AC@, but the
one created here by automake-cvs does.
Re: Support for configure.ac
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 $(top_srcdir)/@CONFIGURE_AC@
%
If autoconf, not automake is responsible for substituting @CONFIGURE_AC@
in the Makefile, then this simply doesn't work with autoconf-2.13, only
with autoconf-cvs.
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_transform
('s/\@TEXI\@/' . $info_cursor . '/g; '
. 's/\@VTI\@/' . $vti . '/g; '
. 's/\@VTEXI\@/' . $vtexi . '/g;'
. 's,\@MDDIR\@,' . $conf_pat . ',g;',
'texi-vers');
Note the lack of the @CONFIGURE_AC@ transform.
- Hari
--
Raja R Harinath -- [EMAIL PROTECTED]
"When all else fails, read the instructions." -- Cahn's Axiom
"Our policy is, when in doubt, do the right thing." -- Roy L Ash
Re: Support for configure.ac
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
| 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_transform
| ('s/\@TEXI\@/' . $info_cursor . '/g; '
| . 's/\@VTI\@/' . $vti . '/g; '
| . 's/\@VTEXI\@/' . $vtexi . '/g;'
| . 's,\@MDDIR\@,' . $conf_pat . ',g;',
| 'texi-vers');
|
| Note the lack of the @CONFIGURE_AC@ transform.
Aaarg! Thank you so much!
But how come I don't have this failure?
~/src/am % touch **/Makefile.am nostromo 18:07
~/src/am % make nostromo 18:08
cd . /home/lrde/prof/akim/src/am/automake --amdir=. --gnits Makefile
cd . \
CONFIG_FILES=Makefile CONFIG_HEADERS= /bin/sh ./config.status
creating Makefile
Making all in .
make[1]: Entre dans le rpertoire `/mnt/nostromo/home/lrde/prof/akim/src/am'
make[1]: *** Pas de rgle pour fabriquer la cible `@CONFIGURE_AC@', ncessaire pour
`stamp-vti'. Arrt.
make[1]: Quitte le rpertoire `/mnt/nostromo/home/lrde/prof/akim/src/am'
make: *** [all-recursive] Erreur 1
Now I have it. Sorry Lars... The test suite did not see anything...
I'm fixing this.
Re: Support for configure.ac
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
===
RCS file: /cvs/automake/automake/automake.in,v
retrieving revision 1.818
diff -u -u -r1.818 automake.in
--- automake.in 2001/01/16 13:31:54 1.818
+++ automake.in 2001/01/18 17:15:57
@@ -2276,10 +2276,11 @@
($conf_pat = $conf_dir) =~ s/(\W)/\\$1/g;
$output_rules .=
file_contents_with_transform
- ('s/\@TEXI\@/' . $info_cursor . '/g; '
-. 's/\@VTI\@/' . $vti . '/g; '
-. 's/\@VTEXI\@/' . $vtexi . '/g;'
-. 's,\@MDDIR\@,' . $conf_pat . ',g;',
+ (transform ('TEXI' = $info_cursor,
+'VTI' = $vti,
+'VTEXI'= $vtexi,
+'MDDIR'= $conf_pat,
+'CONFIGURE_AC' = $configure_ac),
'texi-vers');
push_phony_cleaners ($vti);
@@ -3325,7 +3326,7 @@
}
else
{
-local ($xform) = transform ("CONFIGURE_AC" = $configure_ac);
+local ($xform) = transform ('CONFIGURE_AC' = $configure_ac);
handle_aclocal_m4;
$output_rules .= file_contents_with_transform ($xform,
'remake');
Lars, thanks for your perseverance, and Raja, thanks for helping me.
I think it's time I stop.
PS: After this patch:
~/src/am % touch Makefile.am nostromo 18:15
~/src/am % make nostromo 18:15
cd . /home/lrde/prof/akim/src/am/automake --amdir=. --gnits Makefile
cd . \
CONFIG_FILES=Makefile CONFIG_HEADERS= /bin/sh ./config.status
creating Makefile
Making all in .
make[1]: Entre dans le rpertoire `/mnt/nostromo/home/lrde/prof/akim/src/am'
make[1]: Rien faire pour `all-am'.
make[1]: Quitte le rpertoire `/mnt/nostromo/home/lrde/prof/akim/src/am'
Making all in m4
make[1]: Entre dans le rpertoire `/mnt/nostromo/home/lrde/prof/akim/src/am/m4'
make[1]: Rien faire pour `all'.
make[1]: Quitte le rpertoire `/mnt/nostromo/home/lrde/prof/akim/src/am/m4'
Making all in tests
make[1]: Entre dans le rpertoire `/mnt/nostromo/home/lrde/prof/akim/src/am/tests'
make[1]: Rien faire pour `all'.
make[1]: Quitte le rpertoire `/mnt/nostromo/home/lrde/prof/akim/src/am/tests'
Re: Support for configure.ac
[...] 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;', and it works now! Thanks Raja and Akim.
Re: make install-strip in cross-compilation environments
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' otherwise) in the Alexandre configure script. install-sh already supports STRIPPROG. The problem arises when using the vendor (even GNU) install. Tom
Re: make install-strip in cross-compilation environments
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-strip
Alexandre $(CONFIG_SHELL) /path/to/install-sh' otherwise) in the
Alexandre configure script.
install-sh already supports STRIPPROG.
The problem arises when using the vendor (even GNU) install.
Even better! Then we can just arrange for INSTALL_STRIP to set
STRIPPROG and use install-sh for cross install-strip. install-strip
would pass INSTALL=$(INSTALL_STRIP) to the sub-make, where
INSTALL_STRIP would be set by configure as needed for cross builds.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
More an autopackage
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) written in Python 2) At first, it'll just be a unified front-end to rpm and dpkg and friends. Then, some of the more difficult issues that have been brought up will be tackled, such as package dependencies and automagically deciding the right files and locations for platforms. 3) I think the interface to it will be a file specifying the requirements for the package. Files to include, where to install them, pre and post install scripts, etc. At first, developers just write this file by hand. Even this is a great improvement. Then, automake gets modified to be able to automatically create this spec file. (Is this a good idea?) 4) Is autopackage a good name? 5) I'm really a software developer, not a packaging guy. That's why this seems like such a good idea. I want to write code, not mess with packaging systems. But, I really don't know that much about packaging. So I'll probably need some help with the packaging details. 6) When I get going with Actual Code (TM) (within a couple of weeks), I'll setup a project on sourceforge for this. And finally, thanks to everyone who responded to my initial post. --- Geoffrey Wossum [EMAIL PROTECTED]
Re: OS-sympathetic installation
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!). My own experience is with the Solaris pkgadd/pkgrm family of commands, but other Oses have other things such as "RPM" etc. You're right, it is missing right now. Has any thought been given to this idea? Yes. And I plan to do something about it. I plan to start on a unified front end to all the packaging systems within a couple of weeks. Then automake can use this front-end to create packages. Later on, more advanced stuff will be done with it, such as automagically figuring out package dependencies and such. There's been several posts concering this type of stuff in the past week (check the archive), and I just posted my plans about 5 minutes ago. --- Geoffrey Wossum [EMAIL PROTECTED]
Re: More an autopackage
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, 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?) 5) I'm really a software developer, not a packaging guy. That's why this seems like such a good idea. I want to write code, not mess with packaging systems. But, I really don't know that much about packaging. So I'll probably need some help with the packaging details. 6) When I get going with Actual Code (TM) (within a couple of weeks), I'll setup a project on sourceforge for this. No promises. But I could try to have a quick look at Solaris pkgadd/pkgrm issues once you have got started. -- : David LeeI.T. Service : : Systems Programmer Computer Centre : : University of Durham : : http://www.dur.ac.uk/t.d.lee/South Road: : Durham: : Phone: +44 191 374 2882 U.K. :
Re: More an autopackage
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 that something is considerably less widely installed?)
Because Perl is almost unreadable and Python is a very nice language?
6) When I get going with Actual Code (TM) (within a couple of weeks),
I'll setup a project on sourceforge for this.
No promises. But I could try to have a quick look at Solaris pkgadd/pkgrm
issues once you have got started.
One may find a lot about packaging for native systems in the Samba CVS
tree. See www.samba.org.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: More an autopackage
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? No GNU build tool can be written in a language already used by another tool. Since people already have to know sh, m4, and makefile syntax to use autoconf automake, those three are out, and Perl is out because automake used it. autoILOVEYOU, the GNU viral installer, is written in Visual BASIC and Microsoft Word macros, so autopackage is left with Python. (Perl seems readable enough for automake...) --Rusty
Re: More an autopackage
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?) I originally considered Perl5, basically because automake is in Perl (Perl4 to be precise). But this project screams object-oriented, and Perl's OO support is pretty kludgy. I think Larry Wall even says that in Programming Perl. Python's OOP support is much better. Passing self to every method is kindof kludgy, but overall it's much better than Perl's OO. I've never written a large project in Python, but I have in Perl. Another reason I would choose Python ;) In the same vein, I have noticed a shift in the community's preferred scripting language away from Perl towards Python. This said, I would still probably choose Perl over Python for a quick and dirty script. If someone wants to contribute code to the project, but don't know the implementation language, Python is much easier to learn than Perl. I know a large number of programming languages. C, C++, Java, Visual Basic, Perl, Python, LISP, Scheme, Tcl, Fortran, S370/68k/x86/PIC ASM... most languages that have enjoyed significant popularity except for COBOL. And Perl was by far the most difficult to learn. The install base is an important issue. My Solaris, Tru64, and Irix boxes have Perl, but not Python. But they didn't come with Perl out of the box, somebody had to install Perl. So I don't think also installing Python is that big of a deal. And all modern Linux distros include Perl and Python out of the box. No promises. But I could try to have a quick look at Solaris pkgadd/pkgrm issues once you have got started. Thanks. --- Geoffrey Wossum [EMAIL PROTECTED]
Re: More an autopackage
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 when that something is considerably less widely installed?) I originally considered Perl5, basically because automake is in Perl Aren't we supposed to use GNU guile for all FSF-supported script-based tools? In fact, isn't Automake itself intended to be eventually re-written in guile? If you don't like the current languages that guile supports, you can always write a Python implementation that runs under guile (as they did for Tcl) and implement using Python syntax. Ducking and running ... Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: Support for configure.ac
"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
"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. Tom
Re: More an autopackage
"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 thing is getting the design right; then it can be expressed in any decent language. Geoffrey 3) I think the interface to it will be a file specifying the Geoffrey requirements for the package. Files to include, where to Geoffrey install them, pre and post install scripts, etc. At first, Geoffrey developers just write this file by hand. Even this is a Geoffrey great improvement. Then, automake gets modified to be able Geoffrey to automatically create this spec file. (Is this a good Geoffrey idea?) Automake can't create all of the spec file. It doesn't have enough information. And, adding the information to Makefile.am does not make sense (because it is global to a package, which Makefile.am really isn't). Also, generating a list of files is not enough. You also need pre- and post- install and uninstall commands. One way to get these is the *_INSTALL variables, which I talked about earlier. Another important consideration, I think, is designing the interface that represents the back end. Doing this correctly will allow for plugging in various different back ends. There are probably 6 or 7 package implementations these days... Geoffrey 4) Is autopackage a good name? Yes. Geoffrey So I'll probably need some help with the packaging details. There's lot of reading in your future... Tom
Re: More an autopackage
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:
ATT Software Packages ("pkg"), used by Solaris.
Debian Package Manager ("dpkg")
HP-UX Software Packages ("swinstall" or "depot")
IRIX Software Manager ("inst" or "tardist")
Portable (installation and removal scripts with tar files)
Red Hat Package Manager ("RPM")
--
You provide a list file and epm can generate different packages based on
that. EPM is under GPL. Would it make sense for automake or autopackage to
generate epm list files instead of rpm or dpkg specific scripts?
Ganesan
--
R. Ganesan ([EMAIL PROTECTED]) | Ph: 91-80-5721856 Ext: 2149
Novell India Development Center. | #include std_disclaimer.h
