Hi Stephen, * Stephen Ellwood wrote on Thu, Sep 08, 2005 at 01:16:15AM CEST: > > Im currently writing a fairly nifty software project that makes use of GNU > autotools extensively, although in a very basic way. My aim is to create a > package manager in the style of RPM via automake. Im aiming to create both a > *distro AND platform independent* package manager for Linux.
I won't comment much on this. It's a separate topic, and package dependency issues and theories have been beaten to death in some quite imflammable discussions. I just think it's a hard problem and requires human interaction and work (such as: making a distribution). I'll leave it at that and just comment on the specific issue you have: [ `make uninstall' from a `make clean'ed and subsequently moved source tree ] > Unfortunately when my script jumps into /usr/share/merlin and does make > uninstall it triggers an error. > > Irritatingly when i perform what is essentally the same procedure by entering > commands manually at a terminal things work without problems. Several comments: - First, your moving of the source+build tree: > cp -r ./hello-2.1.1 ~ _must_ preserve time stamps, else you'll have no joy. For GNU coreutils cp, you can use `-a', in general `-p', but time stamp preservation (across system upgrades, for example, or across machines) is a tricky issue, and can require use of `tar' or more than one method depending on the system. Read info Automake "Limitations of Usual Tools" under `cp' and around. - Then, it's often not possible to move the build tree. If you move it back to where it was when you typed `./configure', things should work. (For example, with packages that use libtool this currently does not work in many cases, unfortunately.) - With well-maintained packages closely following GNU standards (haha :), there should be another possibility to achieve what you want: instead of saving the build tree, issue make install make uninstall make install once and record what `make uninstall' does. In theory, it should even be possible to omit the first install step. If the package goes as far as setting NORMAL_INSTALL/POST_INSTALL/PRE_INSTALL and *_UNINSTALL correctly, you should be able to divide (un)installation even further by setting a couple of make variables and observing the runs. Read up on all of this in info standards "Managing Releases" but be warned that not even the most GNUish of programs are likely to obey all of these rules to the last iota. :) (Automake-using packages can come pretty close, though) If you decide to follow one of the latter ideas, and then also decide to file bugs/patches with all packages that do use autotools but not follow all rules there, I'll be both delighted and laughing (and wishing you good luck, of course). :) Cheers, Ralf
