Discussion:
[bakefile-devel] Autoconf uninstall target incompletely undoing installation
Warren Young
2008-08-22 19:38:58 UTC
Permalink
If we have this Bakefile fragment:

<set var="HEADER_DIR">$(PREFIX)/include/some_subdir</set>
<data-files>
<files>lib/*.h</files>
<install-to>$(HEADER_DIR)</install-to>
</data-files>

You get something like this for autoconf output:

install: all install_someproject
$(INSTALL_DIR) $(DESTDIR)$(prefix)/include/some_subdir
(cd $(srcdir) ; $(INSTALL_DATA) lib/*.h \
$(DESTDIR)$(prefix)/include/some_subdir

uninstall: uninstall_someproject
(cd $(DESTDIR)$(prefix)/include/some_subdir ; rm -f *.h)

Notice that it doesn't remove the directory it created.

I tried this to fix it:

<modify-target target="uninstall">
<command>rmdir $(HEADER_DIR)</command>
</modify-target>

but that gets inserted before the Bakefile-generated commands, which
means it can't work because the header files are still there. And, I
can't just rm -r $(HEADER_DIR), because that makes Bakefile's cd-and-rm
command fail.

Obviously one fix is to make uninstall symmetric with regard to install.
Another, which would make Bakefile more flexible, is to add an
attribute (when="after"?) to <modify-target> that would override the
default of inserting the custom commands before the Bakefile ones.
Vaclav Slavik
2008-08-22 23:54:50 UTC
Permalink
Hi,
Post by Warren Young
Obviously one fix is to make uninstall symmetric with regard to install.
There's a problem with that: you don't want "make uninstall" to delete,
say, /usr/local/bin.
Post by Warren Young
Another, which would make Bakefile more flexible, is to add an
attribute (when="after"?) to <modify-target> that would override the
default of inserting the custom commands before the Bakefile ones.
The default actually is to include them after other commands. Where did
you have the <modify-target> block? It should help to move it after the
targets that affect "install"...

Vaclav
Warren Young
2008-08-25 16:06:43 UTC
Permalink
Post by Vaclav Slavik
you don't want "make uninstall" to delete,
say, /usr/local/bin.
True, but that's easily dealt with:

-rmdir $(DIRECTORY_I_MAY_OR_MAY_NOT_HAVE_CREATED)

This would delete the bin directory if the last thing to live in it got
removed, but that should be harmless. It just means anything installing
into it needs to be able to recreate it when necessary.

Ignoring that rare condition, it's equal to "don't remove it unless I
created it".

You're not going to get better behavior without creating an install log
so you can consult it on uninstall to see exactly what was created.
Post by Vaclav Slavik
Where did you have the <modify-target> block?
<dll stuff>
<!-- stuff here -->

<if cond="FORMAT=='autoconf'">
<!-- stuff here -->

<modify-target target="uninstall">
<!-- <command>s here -->
</modify-target>
</if>
</dll>

I don't think that's too surprising, or even wrong. But then after the
<dll> tag:

<data-files>
<files>lib/*.h</files>
<install-to>$(HEADER_DIR)</install-to>
</data-files>

If I move the modify-target after data-files block, it does work. Thanks!
Vaclav Slavik
2008-08-28 19:12:55 UTC
Permalink
Post by Warren Young
-rmdir $(DIRECTORY_I_MAY_OR_MAY_NOT_HAVE_CREATED)
This would delete the bin directory if the last thing to live in it
got removed, but that should be harmless.
True, that's arguably the best thing to do...

Vaclav

Loading...