lmi
[Top][All Lists]
Advanced

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





reply via email to

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