[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lmi] Making a 'clobber' target respect $exec_prefix
From: |
Greg Chicares |
Subject: |
[lmi] Making a 'clobber' target respect $exec_prefix |
Date: |
Thu, 25 May 2017 00:20:24 +0000 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 |
Vadim--I must be doing something wrong, because I see the same undesired
behavior for all of
install_libxml2_libxslt.make
install_wx.make
install_wxpdfdoc.make
I'm building for both 32- and 64-bit msw. When I build for either
architecture, the binaries for the other architecture are wiped out,
even though they're in separate directories. The problem, I suspect, is
that those makefiles make a 'clobber' target first. Let's look at that
target in 'install_wxpdfdoc.make' because I think that's the one you've
modified most recently:
.PHONY: clobber
clobber:
# The 'uninstall_pdfdoc_dll_headers' target doesn't remove the (now empty)
# directory where the headers are installed, so do it separately ourselves.
-cd $(source_dir) && \
$(MAKE) uninstall_pdfdoc_dll uninstall_pdfdoc_dll_headers
-$(RMDIR) $(prefix)/include/wx
-$(RM) --force --recursive $(wxpdfdoc_dir)
That's the same $source_dir where it was last built:
cd $(source_dir) \
&& export PATH="$(mingw_bin_dir):${PATH}" \
&& ./configure $(config_options) \
&& $(MAKE) install_pdfdoc_dll install_pdfdoc_dll_headers \
and it doesn't depend on architecture:
source_dir := $(wxpdfdoc_dir)/wxPdfDoc-$(wxpdfdoc_version)
so I guess what's happening is this:
- I always build in /opt/lmi/wxpdfdoc-scratch
- any leftover state in that scratch directory reflects the last build
- thus, building 32-bit after 64-bit means the 64-bit build is nuked
(and vice versa)
My question, of course, is how to avoid this. It seems to me that I should
establish different *build* directories, so that
make exec_prefix=/opt/lmi/$(HOST)/local host_type=$(HOST) ...
would build in, say,
$(source_dir)/$(HOST)
and therefore clobber would find the last build for that HOST. But is
there some more conventional way to do this--e.g., some standard option
like 'uninstall-architecture=' ?
In my use case, I always want to rebuild these libraries ab ovo--I really
don't modify any of the source files (except by applying patches). That's
why I thought it wise to make 'clobber' first, just to be sure that any
vestiges of earlier errors are wiped clean. I don't suppose that's very
common, but is it really wrong for the work Kim and I do?
On a related subject--is it a bad idea to reuse the same wx source for
multiple builds with different architectures? For example:
make \
prefix=/opt/lmi/local \
exec_prefix=/opt/lmi/$(HOST)/local \
host_type=$(HOST) \
-f install_wx.make
for both x86_64-w64-mingw32 and i686-w64-mingw32, where $prefix is
exactly the same for both. The reason I ask is that I thought wx's
installation process created one header file with configuration
data embedded, and I'm not sure whether that was done in the source
directory itself, on only on a copy placed in $prefix. But the last
time I dug into this was when wx distributed special makefiles for
mingw, so I'm certainly behind the times on this point. In general,
nowadays, if I take care to build in a custom-created subdirectory
of the main wx source directory, then can I safely assume that
cd my_subdir && ../configure && make && make install
will not change anything in the source dir that I cd'd from?
- [lmi] Making a 'clobber' target respect $exec_prefix,
Greg Chicares <=