[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lmi] Managing multiple wx versions
From: |
Greg Chicares |
Subject: |
[lmi] Managing multiple wx versions |
Date: |
Wed, 31 Dec 2008 19:37:51 +0000 |
User-agent: |
Thunderbird 2.0.0.18 (Windows/20081105) |
When building wx using autotools, is there a tidy way to make
the entire wx version number appear in the [msw] dll name and
the wx-config script? Today, e.g., using wx-2.8.9, I have
/opt/lmi/local/lib/cygwxmsw28_gcc_344-0.dll
/opt/lmi/local/lib/libwx_msw-2.8.dll.a
and '/opt/lmi/local/lib/wx-config' is a shortcut to
C:\opt\lmi\local\lib\wx\config\msw-ansi-release-2.8
I suppose this is the intended default behavior because great
care is taken to keep wx-2.A.0 binary-compatible with wx-2.A.n .
What I'm trying to accomplish, though, is quite different: to
keep distinct files for wx-A.B.m and wx-A.B.n all together, so
that I can conveniently run or even rebuild old lmi releases.
This message
http://lists.nongnu.org/archive/html/lmi/2008-12/msg00032.html
suggests a use case. It's helpful if we can pin down specific
versions of wx between which we suspect behavior has changed.
The rule in 'install_wx.make' for building wx is simple:
.PHONY: wx
wx:
../configure $(config_options) && $(MAKE) && $(MAKE) install
and ideally I'd like to set $(config_options) so that I can
run that command, specifically including '$(MAKE) install',
without overwriting the wx binaries for other versions.
$(config_options) already includes a 'VENDOR' designation,
which is currently based on `gcc -dumpversion`. I have the
full wx version available in a variable already; should I
append that to 'VENDOR', or is there a cleaner way?
Of course, if there's a smarter way to solve the problem,
I'd be glad to learn it.
- [lmi] Managing multiple wx versions,
Greg Chicares <=