...btw, if you have separate static and shared wxWidgets libraries, this
model works quite well for segregating these, too!;)

:-Dave S.
----- Original Message -----
From: "Dave Silvia" <dsilvia@...>
To: <wx-users@...>
Cc: "anthemion-devtools" <anthemion-devtools@yahoogroups.com>;
"wxMS_developers" <wxMS_developers@yahoogroups.com>
Sent: Wednesday, March 25, 2009 10:17 PM
Subject: Re: Separate output directories for different Visual Studio
versions


> I've been dealing with this scenario for a couple of years now. It's quite
> simple to deal with. I am a DialogBlocks user and have been almost since
> my first encounter with wxWidgets. At one time I approached Julian Smart
> with my need to have various versions of wxWidgets for my separate builds
> of not only Microsoft platforms, but also my various flavors of GCC. Some
> way to have a central build setup that could share one set of sources
> branched out into many versions for wxWidgets libraries. He saw the need,
> but didn't have any immediate solutions via DialogBlocks or wxWidgets
> proper.
>
> After looking over the build process of wxWidgets, I noticed a variable
> there that was virtually everywhere, but never really used: CFG. This
> variable is appended to the library _and_ build directories universally. I
> brought this to Julian's attention, and after some minor preliminary
> discussion, he included the variable in the property sheet for compiler
> configurations in DialogBlocks. He also installed several DialogBlocks
> variables for the separate MSVCDIR variables (as DialogBlocks designates
> them), however, these are not yet fully implemented in DialogBlocks for
> 'automagic' switching for the individual compiler configurations, but I'm
> sure this will be done at some future date.
>
> Now, this does not mean that I'm advocating you use DialogBlocks (although
> I do believe it is a wise decision for any serious developer to make!;),
> it merely means that, 'yes', there is a way to keep your separate builds.
> When building wxWidgets (using the distributed makefile(s) as DialogBlocks
> does), simply add a command line definition for CFG, e.g.,
> '/DCFG=.VC90.Win32', the resultant directory names in build and lib will
> be 'vc_msw[d].VC90.Win32' and 'vc_lib.VC90.Win32', respectively. All you
> must needs then do is point your individual builds at the appropriate lib
> directory!;)
>
> BTW, another find advantage to DialogBlocks is that it properly builds
> wxWidgets for any platform that the wxWidgets toolkits runs on. It 'knows'
> all the correct parameters to pass to the distribution makefiles to effect
> a correct build for whatever flavor of compiler you might have!:-) Even
> though DialogBlocks is a commercial IDE, its 'forever' evaluation version
> (free!!!) will reliably build wxWidgets for any platform, quite worth its
> price (free!!!?).
>
> HTH:
>
> thx,
> Dave S.
>
> Development with wxWidgets on MSWindows
> http://tech.groups.yahoo.com/group/wxMS_developers/
>
> wxWidgets Code Exchange
> http://wxcodex.net/
>
> ----- Original Message -----
> From: "Kenneth Porter" <shiva.blacklist@...>
> Newsgroups: comp.soft-sys.wxwindows
> To: <wx-users@...>
> Sent: Wednesday, March 25, 2009 8:28 PM
> Subject: Separate output directories for different Visual Studio versions
>
>
>>
>>
>> I need to maintain an app with both VS2005 and VS2008 builds, and will
>> probably soon need to get a VS2010 build going. (Fortunately, I've been
>> able to retire my VC6 build.) Currently I clean my wxWidgets tree and
>> rebuild to switch versions, but it would be nice to be able to leave all
>> versions built in separate output directories. Are there any plans to
>> have
>> that in the standard distro?
>>
>> I'm linking to wx statically (so my demo application and my non-GUI
>> library
>> each have their own copies of wx that don't know about each other), and
>> to
>> the compiler runtime dynamically (application and all 3rd party libraries
>> share one copy of the compiler runtime).
>> _______________________________________________
>> wx-users mailing list
>> wx-users@...
>> http://lists.wxwidgets.org/mailman/listinfo/wx-users
>
> _______________________________________________
> wx-users mailing list
> wx-users@...
> http://lists.wxwidgets.org/mailman/listinfo/wx-users