Hi, On Mon, Nov 28, 2011 at 4:06 PM, Hieu Hoang <[email protected]> wrote: > hi jehan > > I didn't know the autotools build had an uninstall feature.
That's a default feature of the autotools which will follow quite well and closely GNU coding standards (and which make these tools very nice for not having to care about this). Some building targets are part of the coding standards, uninstall being one of them. See: http://www.gnu.org/prep/standards/html_node/Standard-Targets.html So until now, to uninstall Moses, you had to run: $ make uninstall from the same source files that you used (because they kept the configuration of your installation) in order to make a clean uninstall. This is why an admin must keep the installation data (usually in /some/prefix/src/) as long as a package is installed. > 'make release' previously just copied everything to 1 directory of your > choosing, so to uninstall i think you just delete that directory. Is there a > reason why this shouldn't be the case? Moses scripts were *NOT* using the autotools. Only the main Moses installation. Moses scripts had a custom Makefile (which was why one had to edit it by hand, which was quite ugly). So yeah we already had to *just* delete the directory. But the main Moses tools were autotool-ed and having an 'uninstall' target is nice. What is really annoying with such a delete-by-hand method is that you have to track yourself what was part of an installation or not. Typically if the directory for the script is used by other scripts, you can't just remove the whole directory. The main Moses binary files as well will usually go in /some/prefix/bin (default: /usr/local/bin). But typically you have a lot of other binaries in them. If ever the package also install some libraries and headers (I don't think Moses does, but it could), that will be annoying to remove. Same for documentation (man, info, etc.). And so on. Basically a hand uninstallation can potentially leaves out files and makes a prefix dirty. Note that this is not only uninstallation. Normally when you upgrade also, it is advised to uninstall first. Imagine that some script/binary/library/whatever has been removed in the next version and does not exist anymore. If you don't uninstall first, it will leave relics of outdated files (maybe forever). That's it. Jehan > > On 28 November 2011 12:18, Jehan Pages <[email protected]> wrote: >> >> Hi, >> >> last remark. >> With shifting from autotools to bjam, we lost a major installation >> feature: the uninstall target. Couldn't this be added back to bjam? >> >> I always find extremely annoying and frustrating any tool which does >> not provide easy way for a clean uninstall (this is why one uses >> custom prefixes, but still). So now Moses has become one of these >> annoying and frustrating tool. Is it planned to add back an uninstall >> target? Or is it hidden somewhere or with another naming/syntax? >> Thanks! >> >> Jehan >> >> On Mon, Nov 28, 2011 at 2:14 PM, Jehan Pages <[email protected]> wrote: >> > Hi, >> > >> > On Sat, Nov 26, 2011 at 2:57 AM, Kenneth Heafield <[email protected]> >> > wrote: >> >> Hi Moses, >> >> >> >> The root and scripts builds are now integrated into one bjam >> >> build. If you wish to install scripts (formerly make release), use >> >> --install-scripts=/path/to/directory . What formerly involved editing >> >> the Makefile to set the path to giza is now a command line option >> >> --with-giza=/path/to/giza. If you miss timestamped scripts releases, >> >> add --git to tag the directory name with the current git revision. >> > >> > Very nice. This editing-by-hand was quite ugly. >> > As it took me a few try to figure out how the new compilation works, >> > here are my notes about it: >> > >> > 1/ apparently there is no --prefix option anymore? >> > It seems one must install with --install=/my/prefix/bin instead. >> > Also you'll note that the bin/ must be given. I first made the mistake >> > of thinking --install is equivalent to --prefix and I ended up with >> > binaries in the prefix's root. >> > Maybe I missed another option, but it looks like a small loss of >> > usability (--prefix is quite one of the most used feature of >> > Makefile). >> > >> > 2/ --with-xmlrpc-c does not need anymore the xmlrpc-c-config binary >> > path, but the prefix where it is installed. This is good! >> > >> > 3/ The harder was to figure out how to add link flags (LDFLAGS in >> > Makefile). For instance as I use a prefix which is not system-wide, I >> > wanted to add the -l,rpath for finding the lib in runtime. While make >> > would work like: >> > LDFLAGS="-Wl,-rpath=/my/prefix/lib" ./configure [other options] >> > Here, we must do: >> > ./bjam linkflags='-Wl,-rpath=/my/prefix/lib' [other options] >> > >> > 4/ It seems that now multi-thread is the default. Why not, I guess >> > that's for the best (I would have compiled it anyway). >> > >> > 5/ Finally I don't know if this has changed with this commit or >> > slightly before, but I see now Boost must be compiled with 2 >> > additional libraries, Compile Options and Unit Test: >> > --with-libraries=thread,program_options,test >> > I guess that most people don't see this (I imagine that distrib anyway >> > compile everything). I wonder in particular if this is a good idea to >> > have the unit test module compiled as a default option in Moses. >> > Shouldn't it be only for a debug mode? >> > >> > Thanks. >> > >> > Jehan >> > >> >> ./regenerate-makefiles.sh will nag you to use bjam instead. You >> >> may still use autotools for the main build for now, but autotools can >> >> no >> >> longer build scripts. >> >> >> >> Run ./bjam --help for documentation on building Moses with bjam. >> >> >> >> Kenneth >> >> _______________________________________________ >> >> Moses-support mailing list >> >> [email protected] >> >> http://mailman.mit.edu/mailman/listinfo/moses-support >> >> >> > >> >> _______________________________________________ >> Moses-support mailing list >> [email protected] >> http://mailman.mit.edu/mailman/listinfo/moses-support >> > > _______________________________________________ Moses-support mailing list [email protected] http://mailman.mit.edu/mailman/listinfo/moses-support
