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 2>&1 --- 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/
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
Re: More an autopackage
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 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. If we could rely on have a DSO preload feature available, then a clever wrapper could be created that monitors and traps file and directory operations to create the list file. That would eliminate the disk space and time overhead and would get rid of the need to have a "DESTDIR" redirection... Boy, the crazy ideas you get when you are tired... :) -- __ 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: PATCH: make install-strip in cross-compilation environments
On Jan 23, 2001, Alexandre Duret-Lutz <[EMAIL PROTECTED]> wrote: > INSTALL_STRIP_PROGRAM=$$(topsrc_dir)/$(install_sh) -s > and then > install-strip: > $(MAKE) INSTALL_PROGRAM='$(INSTALL_STRIP_PROGRAM)' install > So that $(topsrc_dir) gets evaluated in the sub-make. From > the simulation below, it appears to work fine. The question is, > is it portable? I mean, will any make perform variable substitution > in command line arguments? I don't think so. But then, you can always use: INSTALL_STRIP_PROGRAM=`cd $$(top_srcdir) && pwd`/$(install_sh) $(MAKE) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" 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: 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
Tom Tromey wrote: > ... > Michael>The downside is that you have to somehow clear the > Michael>existing list file before doing this, or only do it > Michael>once, 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
> 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]
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
> "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 :-). Michael>The downside is that you have to somehow clear the Michael>existing list file before doing this, or only do it Michael>once, 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
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: 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
"Derek R. Price" wrote: > ... > Due to security concerns, you're obviously never going to be able > to install files owned by root without root privledges, but are > you really telling me that these systems require you to _build_ > packages as root? For all practical purposes, yes. For Debian, the ownerships and permissions come from the source file; you can't tell dpkg to make all files owned by root:root, etc. For HP-UX, the package files are actually created by a daemon process that runs as root (sigh...); you can tell the daemon to allow non-root users to create packages in certain directories (at least the default is restricted...), but the files that the daemon creates are owned by and readable only by root. It's kinda hard to tar your software depot at that point... :) > If so, how hard would it be to tweak the output files? > > ( sed s/filename:dprice:dprice/filename:root:root/ >newpackage ) Sadly, it isn't that easy... -- __ Michael Sweet, Easy Software Products [EMAIL PROTECTED] Printing Software for UNIX http://www.easysw.com
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: 23-less-ac-subst.patch
This is the result of the two previous patches on the fileutils: @@ -22693,12 +22653,7 @@ s,@ECHO_C@,$ECHO_C,;t t s,@ECHO_N@,$ECHO_N,;t t s,@ECHO_T@,$ECHO_T,;t t -s,@CFLAGS@,$CFLAGS,;t t -s,@CPPFLAGS@,$CPPFLAGS,;t t -s,@CXXFLAGS@,$CXXFLAGS,;t t -s,@FFLAGS@,$FFLAGS,;t t s,@DEFS@,$DEFS,;t t -s,@LDFLAGS@,$LDFLAGS,;t t s,@LIBS@,$LIBS,;t t s,@build@,$build,;t t s,@build_cpu@,$build_cpu,;t t @@ -22727,10 +22682,12 @@ s,@DEPDIR@,$DEPDIR,;t t s,@PERL@,$PERL,;t t s,@CC@,$CC,;t t +s,@CFLAGS@,$CFLAGS,;t t s,@ac_ct_CC@,$ac_ct_CC,;t t s,@OBJEXT@,$OBJEXT,;t t s,@EXEEXT@,$EXEEXT,;t t s,@CPP@,$CPP,;t t +s,@CPPFLAGS@,$CPPFLAGS,;t t s,@CCDEPMODE@,$CCDEPMODE,;t t s,@RANLIB@,$RANLIB,;t t s,@ac_ct_RANLIB@,$ac_ct_RANLIB,;t t @@ -22739,6 +22696,7 @@ s,@OPTIONAL_BIN_ZCRIPTS@,$OPTIONAL_BIN_ZCRIPTS,;t t s,@MAN@,$MAN,;t t s,@DF_PROG@,$DF_PROG,;t t +s,@LDFLAGS@,$LDFLAGS,;t t s,@U@,$U,;t t s,@ANSI2KNR@,$ANSI2KNR,;t t s,@LIBOBJS@,$LIBOBJS,;t t As you can see, only ``right'' ac-substs are kept. /tmp/fileutils-4.0.37 % fgrep CXX configure nostromo 10:59 /tmp/fileutils-4.0.37 % nostromo Err 1 Unfortunately, Tom, this does not suffice to have automake stop from including CXX related definitions in Makefiles: /tmp/fileutils-4.0.37 % automake nostromo 11:00 /tmp/fileutils-4.0.37 % grep CXX Makefile.in nostromo 11:02 CXX = @CXX@ CXXCPP = @CXXCPP@ which, of course, still makes autoscan ask for a C++ compiler: warning: missing AC_PROG_CXX wanted by: Makefile.in:70 tests/Makefile.in:70 tests/touch/Makefile.in:70 tests/shred/Makefile.in:70 tests/rmdir/Makefile.in:70 tests/rm/Makefile.in:70 tests/mv/Makefile.in:70 tests/mkdir/Makefile.in:70 tests/ls-2/Makefile.in:70 tests/ls/Makefile.in:70 tests/ln/Makefile.in:70 tests/install/Makefile.in:70 tests/dircolors/Makefile.in:70 tests/du/Makefile.in:70 tests/dd/Makefile.in:70 tests/cp/Makefile.in:70 tests/chmod/Makefile.in:70 tests/chgrp/Makefile.in:70 m4/Makefile.in:70 man/Makefile.in:69 doc/Makefile.in:70 src/Makefile.in:68 lib/Makefile.in:70 What can we do?