Re: [lmi] Making a 'clobber' target respect $exec_prefix

[Vadim Zeitlin]

On Thu, 25 May 2017 00:20:24 +0000 Greg Chicares <address@hidden> wrote:

GC> Vadim--I must be doing something wrong, because I see the same undesired
GC> behavior for all of
GC>   install_libxml2_libxslt.make
GC>   install_wx.make
GC>   install_wxpdfdoc.make
GC> I'm building for both 32- and 64-bit msw. When I build for either
GC> architecture, the binaries for the other architecture are wiped out,
GC> even though they're in separate directories. The problem, I suspect, is
GC> that those makefiles make a 'clobber' target first.

 Yes, clearly.

GC> Let's look at that target in 'install_wxpdfdoc.make' because I think
GC> that's the one you've modified most recently:

 Not that it matters, but I have no memory of modifying it recently... I
think I must have created it, but I'm almost sure I just "editor inherited"
it from install_wx.make to make it as similar as possible to the existing
file. But I do remember being annoyed by this behaviour, i.e. dependency of
"all" on "clobber" in the past...

GC> so I guess what's happening is this:
GC>  - I always build in /opt/lmi/wxpdfdoc-scratch
GC>  - any leftover state in that scratch directory reflects the last build
GC>  - thus, building 32-bit after 64-bit means the 64-bit build is nuked
GC>    (and vice versa)
GC> My question, of course, is how to avoid this. It seems to me that I should
GC> establish different build directories,

 Yes, this definitely would be my recommendation. I always create a
different build directory for every new build configuration. This does have
its drawbacks (you have to remember to prune the old build directories from
time to time because the space taken by them accumulates rather quickly and
they can fill up even a 1TB SSD in not too much time), but it avoids so
many stupid problems due to something not getting rebuilt correctly that
IME it's really worth it.

GC> so that
GC>   make exec_prefix=/opt/lmi/$(HOST)/local host_type=$(HOST) ...
GC> would build in, say,
GC>   $(source_dir)/$(HOST)
GC> and therefore clobber would find the last build for that HOST. But is
GC> there some more conventional way to do this--e.g., some standard option
GC> like 'uninstall-architecture=' ?

 Not to my knowledge, but then IMHO such option doesn't really make sense
anyhow because it's not really a question of "make" option. Rather, it's a
question of using the right makefile in the first place, i.e. the makefile
in the right directory. If you run several builds in the same directory,
there is no "right" choice, so such option couldn't be made to work. And if
you use one directory per build, then a normal "make uninstall" is enough
and you don't need any new options.

GC> In my use case, I always want to rebuild these libraries ab ovo--I really
GC> don't modify any of the source files (except by applying patches). That's
GC> why I thought it wise to make 'clobber' first, just to be sure that any
GC> vestiges of earlier errors are wiped clean. I don't suppose that's very
GC> common, but is it really wrong for the work Kim and I do?

 For rebuilding ab ovo I would just "rm -rf $(build_dir)". I don't know how
useful is it to run "make uninstall" targets. For one, they're often not
implemented at all (wxWidgets makefile doesn't implement it). Second, even
for automake-generated makefiles like wxPdfDoc one, which do implement it,
it's not going to help if the list of installed files changes in a newer
version because "make uninstall" in it is not going to uninstall the files
installed by the older version.

 This is not to say that "make uninstall" is not useful: it is, but only if
you really want to get rid of the library. If you're going to reinstall it
soon anyhow, it doesn't seem to be useful, you could just as well install
the latest files over the existing ones, knowing that the old files would
be left anyhow.

GC> On a related subject--is it a bad idea to reuse the same wx source for
GC> multiple builds with different architectures?

 No, the source directory is never modified during the build (with one very
unfortunate exception of src/stc/stc.cpp that I should really fix one day,
but this file is only modified if you change Scintilla.iface file and you
wouldn't do this).

GC> For example:
GC> 
GC>   make \
GC>     prefix=/opt/lmi/local \
GC>     exec_prefix=/opt/lmi/$(HOST)/local \
GC>     host_type=$(HOST) \
GC>     -f install_wx.make
GC> 
GC> for both x86_64-w64-mingw32 and i686-w64-mingw32, where $prefix is
GC> exactly the same for both. The reason I ask is that I thought wx's
GC> installation process created one header file with configuration
GC> data embedded, and I'm not sure whether that was done in the source
GC> directory itself, on only on a copy placed in $prefix.

 The header is created under the build directory by configure and then
copied under $libdir by "make install". And libdir is $exec_prefix/lib by
default, so it should be fine.

GC> nowadays, if I take care to build in a custom-created subdirectory
GC> of the main wx source directory, then can I safely assume that
GC>   cd my_subdir && ../configure && make && make install
GC> will not change anything in the source dir that I cd'd from?

 Yes.

 Regards,
VZ