[FFmpeg-cvslog] r21226 - in trunk: Makefile common.mak subdir.mak

[Ivan Kalvachev]

On 1/26/10, M?ns Rullg?rd <mans at mansr.com> wrote:
> Michael Niedermayer <michaelni at gmx.at> writes:
>
>> On Tue, Jan 26, 2010 at 03:44:20AM +0000, M?ns Rullg?rd wrote:
>>> Michael Niedermayer <michaelni at gmx.at> writes:
>>>
>>> > On Mon, Jan 25, 2010 at 03:17:53AM +0000, M?ns Rullg?rd wrote:
>>> >> Baptiste Coudurier <baptiste.coudurier at gmail.com> writes:
>>> >>
>>> >> > On 1/15/10 11:26 AM, Reimar D?ffinger wrote:
>>> >> >> On Fri, Jan 15, 2010 at 08:16:28PM +0100, ramiro wrote:
>>> >> >>> Author: ramiro
>>> >> >>> Date: Fri Jan 15 20:16:28 2010
>>> >> >>> New Revision: 21226
>>> >> >>>
>>> >> >>> Log:
>>> >> >>> Get one step closer to world domination.
>>> >> >>> Remove "make uninstall".
>>> >> >>
>>> >> >> I'm all for a joke, but how about at least printing something
>>> >> >> useful in addition (if you really want after a sleep 1) like
>>> >> >> "Actually this way of uninstalling is just too unreliable, consider
>>> >> >> using a tool like (whatever Mans mentioned) and look in .... for
>>> >> >> files to manually remove").
>>> >> >
>>> >> > Well, I'm all for a joke as well. However I do use make uninstall
>>> >> > and
>>> >> > I know why I'm using it. For example I want to remove the .a from a
>>> >> > static compilation because I want to test shared libs, or vice
>>> >> > versa.
>>> >>
>>> >> That sounds like using the wrong tool for the job.  If you don't want
>>> >> static libs, use --disable-static.  I don't even see how uninstall
>>> >> could possibly be of relevance to what you seem to be describing.
>>> > [...]
>>> >> > Printing the message is fine with me, but keep the uninstall
>>> >> > working.
>>> >> > Thanks for your understanding.
>>> >>
>>> >> Keeping it working takes effort.  I will not waste my time on
>>> >> something that already has superior solutions.
>>> >
>>> > I also think the uninstall target was usefull to some users.
>>>
>>> It was dangerous.  Whatever people may have used if for, there are
>>> better ways to do it.
>>
>> Telling people an unhelpful joke is worse.
>> Worse to them, as some might not know what to do, some might not even
>> understand the joke if they havnt seen the movie.
>> And worse to ffmpeg as it makes the project look quite hostile to its
>> users
>>
>> If instead of this joke a text explaining an alternative solution to the
>> user where presented this would be better.
>> Of course if that text is along the lines of "you should have installed
>> package Y before installing ffmpeg so its installation is loged and can
>> be undone" then again this isnt helpfull to the user because its too late
>> by that time.
>
> I never objected to a note in the documentation.
>
>>> > Would you be ok with baptiste putting it back and maintaining it?
>>>
>>> No.  It's not practical to have different people maintaining their own
>>> little fragments of the makefiles.  Besides, I'm against having that
>>> target there at all.
>>
>> what about a seperate uninstall script?
>> the script gets installed with the other parts and the installed script
>> is run on uninstall and then removed
>
> There's a name for that.  It's called Microsoft Windows.  It has
> almost all the problems of an uninstall make target and some new ones.
> Most importantly, it does nothing to avoid problems with different
> packages installing conflicting files, something a system package
> manager handles trivially.  There's also no promise whatsoever that it
> will do what the user expects.  Consider this:
>
> $ ./configure
> $ make install
> $ ./configure --disable-stuff
> $ make install
> $ /somewhere/uninstall
>
> This will leave behind anything the second configuration disabled,
> just like the uninstall make target would.

Actually the problem in the above example is the `make install` so I
second the idea to remove it too.
The logic is very simple : `make install` would put files that cannot
be removed by the package system, it would unconditionally put
conflicting files in different places or already installed packages.
That's why users should not be allowed to run it. Package maintainers
are smart enough to figure out what files are needed anyway.~~

Actually always installing into subdirectory of ffmpeg is looking like
good idea the more I think about it. There are some problems... but
nothing install.sh can't fix.