lmi
[Top][All Lists]
Advanced

[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?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]