Hi,
If you specify the same options (including --install) followed by
--clean, it will also delete the installed files.
Kenneth
On 11/28/11 07:24, Jehan Pages wrote:
> 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
