Re: More an autopackage
Geoffrey Wossum wrote: ... the job right now. For instance, our packages are supposed to have a pre-install script that does a click-through agreement. I've tried to explain that you can tell the package system (rpm, at least) not to run pre-install scripts and therefore it probably wouldn't hold up in court. But anyway, the powers that be want that pre-install script capability, which epm doesn't seem to support. Actually, you could probably steal the script stuff from the portable.c file that shows the license agreement. I wouldn't wait for the response (that would break GUI installers), but at least you can cat out the license agreement to the screen... ... generates the epm list file. It's double work, but eventually autopkg would get support for "native" package systems. Then later autopkg will be able to scan Makefile/Makefile.am/some_file to automatically generate its install info file. We're hoping to extend EPM in v3.0 to support sub-packages and other things so that you can utilize more of the RPM/Debian/PKG/DEPOT/INST capabilities. We also have some beta patches that add AIX support (probably go into 2.4), so the list file approach may give you the best bang for the buck, and you won't have to worry so much about dealing with the subtleties of RPM, etc. FWIW, here is a quick rundown of what we're planning to add in future releases of EPM: 2.3 (to be released this week) - Better init.d script location for RPM distributions (makes them portable to multiple Linux dists) - Better directory and config file support for HP-UX - Variable definition in list files (e.g. "$prefix=/dir"), overridden by env or command-line options. 2.4 and beyond - AIX packager support - Better wildcard support (for directories as well as files) - Pre-install commands - Better config file support for packagers that don't know what a config file is. - Better dependency support (version numbers as well as packages) - Sub-package support (e.g. package and package-devel, or package and package.devel, etc.) - BSD-style install script that builds list files for you. -- __ Michael Sweet, Easy Software Products [EMAIL PROTECTED] Printing Software for UNIX http://www.easysw.com
Re: PATCH: patsubst support
Hello!
Trying to catch up with the mailing lists :-)
I'm surprised that this patch has not been applied since October. I
believe it's very valuable. I even considered doing it myself.
b) default static expansion to off, avoids surprising anyone depending
on dynamic expansion by make, retains the same non-portable
default behavour as current CVS.
# Makefile.in fragment
FOO = foo bar
BAR = ${FOO:%=%.c}
This would be wrong. This is only acceptable in the developer's
environment, i.e. not in the makefiles created by "make dist". But I see
no serious reason to generate different makefiles in this case.
Regards,
Pavel Roskin
Re: More an autopackage
On Mon, Jan 22, 2001 at 09:49:04PM -0500, 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 will be owned by your user group. Paraphrasing Rusty Ballinger, dpkg "wants" you to be root, but you can fake it. I regularly build packages as a non-privileged user. The LD_PRELOAD tricks that "fakeroot" plays will result in a tarfile full of "root-owned" files. -Steve
Re: More an autopackage
"Michael" == Michael Sweet [EMAIL PROTECTED] writes: Michael http://www.easysw.com/epm I haven't tried this, but I read through the web site, and it definitely looks like what I'd like out of an `autopackage'. Michael 1. Provide an install-sh like script that appends the Michael installed file(s) or directories to and intermediate list Michael file. This will usually mean that you can wire existing Michael apps' makefiles to install into the list file, which then Michael can be used to build an actual distribution. This is an attractive idea, but it doesn't work if you also want to extract the post/pre-install/uninstall commands automatically. And you definitely do want to do this because sometimes these are hairy scripts generated by automake itself. One approach, which ought to work, would be to use the install-sh hack and then scan each generated Makefile looking for the magic *_INSTALL variable instance. Then you could have a small script to extract these fragments automatically. This is a bit ugly, but it ought to work ok, at least with automake-generated Makefiles (the only ones I care about :-). MichaelThe downside is that you have to somehow clear the Michaelexisting list file before doing this, or only do it Michaelonce, so that you have the correct set of files... I don't understand this. How does EPM handle the case where there are multiple binary packages in a single source package? Michael 2. Provide some sort of script or tool to scan makefiles, Michael looking at the install targets and somehow figuring out Michael what files are getting installed. This is an ambitious Michael project in itself, and probably isn't worth the trouble. I agree. This could be very hard. Take a look at the ugly Makefiles generated by automake... Michael A third option in the context of an autopackage program is to Michael provide "AP" macros that are used to build both install rules Michael in the makefiles and entries in the list file. This would work but would probably require extensive work on automake. That makes it unlikely. Anyway, I'm really glad to find out about EPM. I had never heard of it until this discussion. I'm definitely interested in enhancing automake to make EPM's job easier, if that is possible. Tom
Automake shooting in its foot
I tracked down the CXX definition in the fileutils' Makefile.ins, and it's damned stupid... Automake comes with its own set of macros, for instance to set up AM_DEPENDENCIES. Whoever uses automake will include these macros in aclocal.m4. Then automake, when scanning aclocal.m4 will find AC_PROG_CC, AC_PROG_CXX etc. in there, and will conclude that the package uses CC, CXX etc. and will define those vars. Seeing this autoscan will ask for an actual use of AC_PROG_CC, since it knows for real what is used and what is not: it uses autoconf's --trace... Actually it is just the same when running autoscan on Automake: because of aclocal.m4 you'll have: ~/src/automake-1.4c % ../ace/autoscan -A ../ace 0:35 remo warning: missing AC_PROG_CC wanted by: Makefile.in:64 m4/Makefile.in:64 tests/Makefile.in:64 warning: missing AC_PROG_CPP wanted by: Makefile.in:65 m4/Makefile.in:65 tests/Makefile.in:65 warning: missing AC_PROG_CXX wanted by: Makefile.in:66 m4/Makefile.in:66 tests/Makefile.in:66 So, IMHO, we have just no issue until we release an autoconf --trace aware automake. And frankly, I can't wait :) Automake will be much shorter (less hard coded knowledge on Autoconf), more robust (less hard coded knowledge on Autoconf), and more extendible (less hard coded knowledge on Autoconf). It'd be great if the Autotools could decide for real that once their 2.50, 1.5 and 1.4 version release, we should make a stop, releasing about the same packages with very few changes, but requiring 2.50 or 2.51. Automake will require autoconf --trace and drop dead compatibility with older Autoconves, and Libtool too, taking advantage of a decided and clean means to hook its stuff to Autoconf's AC_PROG_CC etc. (likewise for Automake's dependency tracking macros). AC_PROG_CC and the like are overloaded to death, and I don't want to be there when they blow out.
Re: More an autopackage
Actually, you could probably steal the script stuff from the portable.c file that shows the license agreement. I wouldn't wait for the response (that would break GUI installers), but at least you can cat out the license agreement to the screen... But just displaying the license doesn't have any legal force. The user has to be forced to "click-through". For free software purposes, this isn't a big deal, but it is for commercial software. We're hoping to extend EPM in v3.0 to support sub-packages and other things so that you can utilize more of the RPM/Debian/PKG/DEPOT/INST capabilities. We also have some beta patches that add AIX support (probably go into 2.4), so the list file approach may give you the best bang for the buck, and you won't have to worry so much about dealing with the subtleties of RPM, etc. As far as sub-packages go, it isn't a big deal to make subpackages with epm 2.2. You just make a seperate list file for each package. autopkg could just generate seperate list files, and epm could concentrate on handling the details of the packager. This doesn't help people who want to use epm in isolation. But people using epm in isolation have to manually write list files anyway. - Variable definition in list files (e.g. "$prefix=/dir"), overridden by env or command-line options. I had a .in file that configure was macro substituting to get the same effect. - Better dependency support (version numbers as well as packages) I assume this requires coorperation with the underlying platform packager? --- Geoffrey Wossum [EMAIL PROTECTED]
Re: More an autopackage
Tom Tromey wrote: ... MichaelThe downside is that you have to somehow clear the Michaelexisting list file before doing this, or only do it Michaelonce, so that you have the correct set of files... I don't understand this. Basically, the install-sh hack would append to an existing list file. If you run through the virtual install that creates the list file more than once, then you'll end up with multiple copies of files (EPM does filter this out.) Even worse, tho, is that you might end up with a mix of new and old files in the list files, which EPM won't catch... How does EPM handle the case where there are multiple binary packages in a single source package? Right now you build a single package from a single list file. There is nothing preventing that package from containing multiple programs, but you can't install them separately (i.e. no sub-package support, at least not yet...) -- __ Michael Sweet, Easy Software Products [EMAIL PROTECTED] Printing Software for UNIX http://www.easysw.com
Re: More an autopackage
On Jan 22, 2001, Michael Sweet [EMAIL PROTECTED] wrote:
What it doesn't do (yet) is provide a tool to automate the creation
of the list file.
make install DESTDIR=/tmp/install
find /tmp/install/. ! -name . -print | sed 's,^/tmp/install,,'
rm -rf /tmp/install
--
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
Geoffrey Wossum wrote:
Actually, you could probably steal the script stuff from the
portable.c file that shows the license agreement. I wouldn't wait
for the response (that would break GUI installers), but at least
you can cat out the license agreement to the screen...
But just displaying the license doesn't have any legal force. The
user has to be forced to "click-through". For free software
purposes, this isn't a big deal, but it is for commercial software.
Believe me, I know all about commercial issues, but if you are going
to use the RPM format you can't depend on using the console to
confirm, or even the GUI.
FWIW, the EPM portable format also comes with an InstallShield-
style setup program that shows the license agreement in the window
(the same scripts show the license on the console if installed
without the setup GUI...)
...
As far as sub-packages go, it isn't a big deal to make subpackages
with epm 2.2. You just make a seperate list file for each package.
Right, but that doesn't help when you want a single package with
optional parts, which more closely matches the IRIX, HP-UX, and
Solaris packagers.
...
I had a .in file that configure was macro substituting to get the
same effect.
The advantage with the variable support is that it works around
the ${prefix} that usually ends up in exec_prefix, etc.
...
I assume this requires coorperation with the underlying platform
packager?
Yes. The main issue is to support the version dependencies in the
portable distributions - the RPM, inst, etc. formats can already
be easily extended to support the version numbers since they support
them natively.
--
__
Michael Sweet, Easy Software Products [EMAIL PROTECTED]
Printing Software for UNIX http://www.easysw.com
Re: Automake shooting in its foot
On Jan 23, 2001, [EMAIL PROTECTED] wrote:
So, IMHO, we have just no issue until we release an autoconf --trace
aware automake. And frankly, I can't wait :) Automake will be much
shorter (less hard coded knowledge on Autoconf), more robust (less
hard coded knowledge on Autoconf), and more extendible (less hard
coded knowledge on Autoconf).
:-)
Meanwhile, can't we just hide the uses of AC_PROG_CC and _CXX from
automake by adding ][ in the middle of their names?
--
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
"Michael" == Michael Sweet [EMAIL PROTECTED] writes: Alexandre Oliva wrote: On Jan 22, 2001, Michael Sweet [EMAIL PROTECTED] wrote: What it doesn't do (yet) is provide a tool to automate the creation of the list file. make install DESTDIR=/tmp/install find /tmp/install/. ! -name . -print | sed 's,^/tmp/install,,' rm -rf /tmp/install This is exactly what I had in mind in combination with package specific install (i.e. make install-package-foo, make install-package-foolib etc. This isn't an improvement over the existing RPM an dpkg paradigm; installing all files to a temporary directory wastes disk space (please, disk space is cheap but how many of us have unlimited space) and precious build/development time. You normally *have* to package only installed binaries, especially with libtool libraries. Ganesan -- R. Ganesan ([EMAIL PROTECTED]) | Ph: 91-80-5721856 Ext: 2149 Novell India Development Center. | #include std_disclaimer.h
Re: using pswrap
hi Tom,
thank you so much for your help! your advice was fantastic. whoops... i
just noticed your name on the autotools book! no wonder!
anyway, everything you mentioned was documented in the "info" file so
you don't have to worry about adding anything.
based on your advice i created my code/Makefile.am as follows:
---
SUFFIXES = .psw .h
bin_PROGRAMS = example
example_SOURCES = example.c wraps.c
EXTRA_DIST = wraps.psw
BUILT_SOURCES = wraps.c wraps.h
CLEANFILES = wraps.h wraps.c
example_LDADD = $(X_LIBS) $(X_PRE_LIBS) -lX11 $(X_EXTRA_LIBS)
INCLUDES = $(X_CFLAGS)
.psw.c:
pswrap -a -o ${@} $
.psw.h:
pswrap -a -h ${@} $ /dev/null 21
---
and i also included the following in the top-level Makefile.am:
---
dist-hook:
$(RM) $(distdir)/code/wraps.c
---
and everything works the way i want it to. when i tried adding the
"wraps.psw" to the "example_SOURCES" line, gcc kept trying to compile
the "wraps.h" file!
---
gcc -g -O2 -o example example.o wraps.o wraps.h -L/usr/X11R6/lib
-lSM -lICE -lX11 -ldps -lXt
gcc: Compilation of header file requested
make[2]: *** [example] Error 1
---
thanks again for your help, if anything looks wrong or out-of-place
don't hesitate to educate me.
best regards,
trevor
--
http://home.ica.net/~vjbtlw/
