Overriding properties in Visual Studio
651 views
Skip to first unread message
Ray Satiro
Jun 29, 2014, 2:22:14 PM6/29/14
to wx-...@googlegroups.com
Hello,
I had a problem using your Visual Studio project files and I have an idea for a fix. I have been unable to register for your bug tracker, so I will post my idea here.
I use Visual Studio 2010, 2012 and 2013 and I wanted to build several versions of the wxWidgets library. The
file docs/msw/install.txt says that a local.props file can be used to override the property wxCompilerPrefix, among others. I set that prefix to vc100, vc110, vc120 respectively in each local props file that I created so that I could separate my builds. But it seems the local props file only overrides properties defined after wx_vcN_wx_setup.props, and therefore composite properties (properties made from other properties) in that setup file do not receive the overridden values. For example the setup props has wxOutDir that might be for example like this:
..\..\lib\$(wxCompilerPrefix)$(wxArchSuffix)_dll$(wxCfg)\
The way things are now wxCompilerPrefix is always its default of vc since any wxCompilerPrefix override in the local props file is only defined after wxOutDir. In other words when Visual Studio reads in the properties it looks like this:
--wx_vc12_wx_setup.props--
<wxCompilerPrefix>vc</wxCompilerPrefix>
<wxOutDir>..\..\lib\$(wxCompilerPrefix)$(wxArchSuffix)_dll$(wxCfg)\</wxOutDir>
<wxOutDir>..\..\lib\$(wxCompilerPrefix)$(wxArchSuffix)_dll$(wxCfg)\</wxOutDir>
--
--wx_vc12_local.props--
<wxCompilerPrefix>vc120</wxCompilerPrefix>
--
wxCompilerPrefix == vc120
wxOutDir == ..\..\lib\vc_dll\
Unfortunately Visual Studio doesn't allow for delayed property expansion... does it? I tried this for example but it didn't work..
$([System.String]::new("(wxCompilerPrefix)").Insert(0, '$'))
I guess it could be a solution to place the local.props before setup.props but if you do that then you'd have to check each variable in the setup.props to see if it was already set, for example:
<wxCompilerPrefix Condition="'$(wxCompilerPrefix)'==''">vc</wxCompilerPrefix>
Another way to allow the user to override those properties while still allowing the
composite properties to receive the overridden values is to import the local.props in setup.props after the base property group is defined but before the composite properties, so when Visual Studio reads it in it looks like this:
--wx_vc12_wx_setup.props--
<wxCompilerPrefix>vc</wxCompilerPrefix>
<Import Condition="Exists('wx_vc12_local.props')" Project="wx_vc12_local.props"/>
<Import Condition="Exists('wx_vc12_local.props')" Project="wx_vc12_local.props"/>
--wx_vc12_local.props--
<wxCompilerPrefix>vc120</wxCompilerPrefix>
--
<wxOutDir>..\..\lib\$(wxCompilerPrefix)$(wxArchSuffix)_dll$(wxCfg)\</wxOutDir>
<wxOutDir>..\..\lib\$(wxCompilerPrefix)$(wxArchSuffix)_dll$(wxCfg)\</wxOutDir>
--
wxCompilerPrefix == vc120
wxOutDir == ..\..\lib\vc120_dll\
By doing it that way anything above the import line is overridden but below the import line is not. Ultimately though that is the change I made to get it working. And I updated the install document to reflect that Visual Studio 2010 can also have a props file. You can view the two commits here and the commit messages by clicking on each ...
If you accept these changes please let me know how you want me to proceed. As I said I cannot post on the tracker. It looks like this is an ongoing issue not just for me so I will stay subscribed to this e-mail list for now.
Two other notes that may help anyone making multiple builds. I wanted to run the samples but those are all based on the generic vc directories so I linked my Visual Studio 2013 build via directory junctions.
In build\msw:
mklink /J vc_mswu vc120_mswu
mklink /J vc_mswud vc120_mswud
mklink /J vc_mswuddll vc120_mswuddll
mklink /J vc_mswudll vc120_mswudll
In lib:
mklink /J vc_dll vc120_dll
mklink /J vc_lib vc120_lib
That way I copy a sample's project file that I want like minimal_vc9.vcproj to minimal_vc12.vcproj and when I open it in Visual Studio 2013 it converts it to minimal_vc12.vcxproj and I can just press F5 and run the sample without having to modify the directory locations.
Another thing bothering me was there's no ignore list in the repo for the files Visual Studio versions create so I added my own to .git/info/exclude (my local gitignore):
include/wx/msw/setup.h
build/msw/*_local.props
build/msw/*.opensdf
build/msw/*.sdf
build/msw/*.suo
build/msw/*.user
build/msw/enc_temp_folder/
build/msw/ipch/
build/msw/vc*/
lib/vc*/
Thanks to all the developers and contributors for your work on this project
Vadim Zeitlin
Jun 29, 2014, 7:37:45 PM6/29/14
to wx-...@googlegroups.com
On Sun, 29 Jun 2014 10:26:13 -0700 'Ray Satiro' via wx-dev wrote:
RS> I use Visual Studio 2010, 2012 and 2013 and I wanted to build
RS> several versions of the wxWidgets library. The file
RS> docs/msw/install.txt says that a local.props file can be used to
RS> override the property wxCompilerPrefix, among others.
The thing that it doesn't say is that you actually need to copy
wx_vcN_wx_setup.props to wx_vcN_local.props and only then modify it. I.e.
the local.props file needs to contain everything and not just the options
that you want to change. I agree that it's somewhat counterintuitive and at
the very least should be explained better.
RS> Another way to allow the user to override those properties while still
RS> allowing the composite properties to receive the overridden values is
RS> to import the local.props in setup.props after the base property
RS> groupis defined but before the composite properties, so when Visual
RS> Studio reads it in it looks like this:
RS>
RS> --wx_vc12_wx_setup.props--
RS> <wxCompilerPrefix>vc</wxCompilerPrefix>
RS> <Import Condition="Exists('wx_vc12_local.props')" Project="wx_vc12_local.props"/>
RS> --wx_vc12_local.props--
RS> <wxCompilerPrefix>vc120</wxCompilerPrefix>
RS> --
RS> <wxOutDir>..\..\lib\$(wxCompilerPrefix)$(wxArchSuffix)_dll$(wxCfg)\</wxOutDir>
RS> --
RS>
RS> wxCompilerPrefix == vc120
RS> wxOutDir == ..\..\lib\vc120_dll\
RS>
RS> By doing it that way anything above the import line is overridden but
RS> below the import line is not. Ultimately though that is the change I
RS> made to get it working. And I updated the install document to reflect
RS> that Visual Studio 2010 can also have a props file. You can view the
RS> two commits here and the commit messages by clicking on each ...
RS>
RS> https://github.com/jay/wxWidgets/compare/d201caa...propsfix1
I rather like this. Artur, do you see any problems with doing it like
this?
RS> If you accept these changes please let me know how you want me to
RS> proceed.
The troublesome thing is that we're going to replace the current projects
from the ones from this message:
https://groups.google.com/d/msg/wx-dev/WZhS_Jh3zD4/EORznSIw3UYJ
soon, so the patch is not going to apply anyhow. OTOH it is simple enough
to be reapplied manually to the new projects, I think.
RS> As I said I cannot post on the tracker. It looks like this is an
RS> ongoing issue not just for me so I will stay subscribed to this e-mail
RS> list for now.
This should be fixed now, sorry about that problem.
RS> Two other notes that may help anyone making multiple builds. I wanted
RS> to run the samples but those are all based on the generic vc
RS> directories
IMHO the simplest way to build the samples when using non-default compiler
prefix is by using nmake with COMPILER_PREFIX=vc120 (or whatever) on its
command line. The main problem with nmake is lack of dependencies and,
also, that it doesn't build in parallel, but both matter much less for the
samples than for the library itself.
RS> Another thing bothering me was there's no ignore list in the repo for
RS> the files Visual Studio versions create so I added my own to
RS> .git/info/exclude (my local gitignore):
RS> include/wx/msw/setup.h
RS> build/msw/*_local.props
RS> build/msw/*.opensdf
RS> build/msw/*.sdf
RS> build/msw/*.suo
RS> build/msw/*.user
RS> build/msw/enc_temp_folder/
RS> build/msw/ipch/
RS> build/msw/vc*/
RS> lib/vc*/
Yes, we should have .gitignore, I have pretty much the same locally too
and I guess everybody else does as well. Although I don't know what are
enc_temp_folder and ipch directories, I don't have those.
Regards,
VZ
RS> I use Visual Studio 2010, 2012 and 2013 and I wanted to build
RS> several versions of the wxWidgets library. The file
RS> docs/msw/install.txt says that a local.props file can be used to
RS> override the property wxCompilerPrefix, among others.
The thing that it doesn't say is that you actually need to copy
wx_vcN_wx_setup.props to wx_vcN_local.props and only then modify it. I.e.
the local.props file needs to contain everything and not just the options
that you want to change. I agree that it's somewhat counterintuitive and at
the very least should be explained better.
RS> Another way to allow the user to override those properties while still
RS> allowing the composite properties to receive the overridden values is
RS> to import the local.props in setup.props after the base property
RS> groupis defined but before the composite properties, so when Visual
RS> Studio reads it in it looks like this:
RS>
RS> --wx_vc12_wx_setup.props--
RS> <wxCompilerPrefix>vc</wxCompilerPrefix>
RS> <Import Condition="Exists('wx_vc12_local.props')" Project="wx_vc12_local.props"/>
RS> --wx_vc12_local.props--
RS> <wxCompilerPrefix>vc120</wxCompilerPrefix>
RS> --
RS> <wxOutDir>..\..\lib\$(wxCompilerPrefix)$(wxArchSuffix)_dll$(wxCfg)\</wxOutDir>
RS> --
RS>
RS> wxCompilerPrefix == vc120
RS> wxOutDir == ..\..\lib\vc120_dll\
RS>
RS> By doing it that way anything above the import line is overridden but
RS> below the import line is not. Ultimately though that is the change I
RS> made to get it working. And I updated the install document to reflect
RS> that Visual Studio 2010 can also have a props file. You can view the
RS> two commits here and the commit messages by clicking on each ...
RS>
RS> https://github.com/jay/wxWidgets/compare/d201caa...propsfix1
I rather like this. Artur, do you see any problems with doing it like
this?
RS> If you accept these changes please let me know how you want me to
RS> proceed.
The troublesome thing is that we're going to replace the current projects
from the ones from this message:
https://groups.google.com/d/msg/wx-dev/WZhS_Jh3zD4/EORznSIw3UYJ
soon, so the patch is not going to apply anyhow. OTOH it is simple enough
to be reapplied manually to the new projects, I think.
RS> As I said I cannot post on the tracker. It looks like this is an
RS> ongoing issue not just for me so I will stay subscribed to this e-mail
RS> list for now.
This should be fixed now, sorry about that problem.
RS> Two other notes that may help anyone making multiple builds. I wanted
RS> to run the samples but those are all based on the generic vc
RS> directories
IMHO the simplest way to build the samples when using non-default compiler
prefix is by using nmake with COMPILER_PREFIX=vc120 (or whatever) on its
command line. The main problem with nmake is lack of dependencies and,
also, that it doesn't build in parallel, but both matter much less for the
samples than for the library itself.
RS> Another thing bothering me was there's no ignore list in the repo for
RS> the files Visual Studio versions create so I added my own to
RS> .git/info/exclude (my local gitignore):
RS> include/wx/msw/setup.h
RS> build/msw/*_local.props
RS> build/msw/*.opensdf
RS> build/msw/*.sdf
RS> build/msw/*.suo
RS> build/msw/*.user
RS> build/msw/enc_temp_folder/
RS> build/msw/ipch/
RS> build/msw/vc*/
RS> lib/vc*/
Yes, we should have .gitignore, I have pretty much the same locally too
and I guess everybody else does as well. Although I don't know what are
enc_temp_folder and ipch directories, I don't have those.
Regards,
VZ
Ray Satiro
Jun 29, 2014, 11:04:22 PM6/29/14
to wx-...@googlegroups.com
On 6/29/2014 7:37 PM, Vadim Zeitlin wrote:
> On Sun, 29 Jun 2014 10:26:13 -0700 'Ray Satiro' via wx-dev wrote:
>
> RS> I use Visual Studio 2010, 2012 and 2013 and I wanted to build
> RS> several versions of the wxWidgets library. The file
> RS> docs/msw/install.txt says that a local.props file can be used to
> RS> override the property wxCompilerPrefix, among others.
>
> The thing that it doesn't say is that you actually need to copy
> wx_vcN_wx_setup.props to wx_vcN_local.props and only then modify it. I.e.
> the local.props file needs to contain everything and not just the options
> that you want to change. I agree that it's somewhat counterintuitive and at
> the very least should be explained better.
Ok. I've never seen it done that way in practice, it strikes me as kind
> On Sun, 29 Jun 2014 10:26:13 -0700 'Ray Satiro' via wx-dev wrote:
>
> RS> I use Visual Studio 2010, 2012 and 2013 and I wanted to build
> RS> several versions of the wxWidgets library. The file
> RS> docs/msw/install.txt says that a local.props file can be used to
> RS> override the property wxCompilerPrefix, among others.
>
> The thing that it doesn't say is that you actually need to copy
> wx_vcN_wx_setup.props to wx_vcN_local.props and only then modify it. I.e.
> the local.props file needs to contain everything and not just the options
> that you want to change. I agree that it's somewhat counterintuitive and at
> the very least should be explained better.
of unusual. Usually there is inheritance, and the inheritance is ordered
so that the user can override some properties with their own property
file. I know that must sound a lot like what you're talking about but
not all properties need to be redefined. In other words the overriding
props file is not a copy of a parent, it contains only base properties
to be overridden. Say in the future you need to push out a change to
setup.props logic (condition,item,something other than a property,
etcetc) then there's still the user's local.props with the bad logic
from your setup.props since it was a copy from some earlier point.
However in this case since there are composite properties (I'm just
calling them that -- there may be proper terminology for it that I
haven't heard of) that pull from properties that the user can override
then you have a more complex problem because you want the user to be
able to override certain base properties and you want the composite
properties to be made from the overridden base properties. I've seen
that done in 3 ways. 1) a stub props file and some logic for import
statements weaving in user and official props files conditionally, 2)
the official props file with an import to the user's props or 3) the
user's props if any (the import and check has to be in the project file
if I recall) is imported before the official props and then the official
props can check any potential already defined property with condition
='' before doing a definition.
I suspect a lot of that could be solved with delayed property expansion,
but if there's a way to do that I haven't found it and based on the
projects I've seen and those methods that they're using I'm pretty sure
others haven't either. Which is unusual because items do have delayed
expansion, in some cases. Maybe someone knows the answer to this mystery?
> RS> If you accept these changes please let me know how you want me to
> RS> proceed.
>
> The troublesome thing is that we're going to replace the current projects
> from the ones from this message:
>
> https://groups.google.com/d/msg/wx-dev/WZhS_Jh3zD4/EORznSIw3UYJ
>
> soon, so the patch is not going to apply anyhow. OTOH it is simple enough
> to be reapplied manually to the new projects, I think.
do let me know. This is a pretty high traffic mailing list so it's
likely I will unsubscribe when this thread goes stale but you can always
e-mail me directly.
> RS> As I said I cannot post on the tracker. It looks like this is an
> RS> ongoing issue not just for me so I will stay subscribed to this e-mail
> RS> list for now.
>
> This should be fixed now, sorry about that problem.
list that it was a temporary issue affecting a wide range of sites.
> RS> Another thing bothering me was there's no ignore list in the repo for
> RS> the files Visual Studio versions create so I added my own to
> RS> .git/info/exclude (my local gitignore):
> RS> include/wx/msw/setup.h
> RS> build/msw/*_local.props
> RS> build/msw/*.opensdf
> RS> build/msw/*.sdf
> RS> build/msw/*.suo
> RS> build/msw/*.user
> RS> build/msw/enc_temp_folder/
> RS> build/msw/ipch/
> RS> build/msw/vc*/
> RS> lib/vc*/
>
> Yes, we should have .gitignore, I have pretty much the same locally too
> and I guess everybody else does as well. Although I don't know what are
> enc_temp_folder and ipch directories, I don't have those.
think it's used during edit and continue. ipch is the precompiled header
folder.
Vadim Zeitlin
Jun 30, 2014, 7:55:47 AM6/30/14
to wx-...@googlegroups.com
On Sun, 29 Jun 2014 23:04:14 -0400 'Ray Satiro' via wx-dev wrote:
RS> On 6/29/2014 7:37 PM, Vadim Zeitlin wrote:
RS> > RS> several versions of the wxWidgets library. The file
RS> > RS> docs/msw/install.txt says that a local.props file can be used to
RS> > RS> override the property wxCompilerPrefix, among others.
RS> >
RS> > The thing that it doesn't say is that you actually need to copy
RS> > wx_vcN_wx_setup.props to wx_vcN_local.props and only then modify it. I.e.
RS> > the local.props file needs to contain everything and not just the options
RS> > that you want to change. I agree that it's somewhat counterintuitive and at
RS> > the very least should be explained better.
RS>
RS> Ok. I've never seen it done that way in practice, it strikes me as kind
RS> of unusual.
...
RS> Maybe someone knows the answer to this mystery?
Again, I definitely agree that it would be nice to improve this, but I'm
not an MSBuild expert by any stretch of imagination, so I really don't know
what would be the proper way to do it.
RS> > RS> If you accept these changes please let me know how you want me to
RS> > RS> proceed.
RS> >
RS> > The troublesome thing is that we're going to replace the current projects
RS> > from the ones from this message:
RS> >
RS> > https://groups.google.com/d/msg/wx-dev/WZhS_Jh3zD4/EORznSIw3UYJ
RS> >
RS> > soon, so the patch is not going to apply anyhow. OTOH it is simple enough
RS> > to be reapplied manually to the new projects, I think.
RS>
RS> Ok. I appreciate your need for consolidation. If there's anything I can
RS> do let me know. This is a pretty high traffic mailing list so it's
RS> likely I will unsubscribe when this thread goes stale but you can always
RS> e-mail me directly.
Any tested and working patches to the new unified project files would be
welcome. In fact, even right now testing these new projects would be very
useful too -- please follow up if you do this and tell us how they worked
for you.
RS> > RS> Another thing bothering me was there's no ignore list in the repo for
RS> > RS> the files Visual Studio versions create so I added my own to
RS> > RS> .git/info/exclude (my local gitignore):
RS> > RS> include/wx/msw/setup.h
RS> > RS> build/msw/*_local.props
RS> > RS> build/msw/*.opensdf
RS> > RS> build/msw/*.sdf
RS> > RS> build/msw/*.suo
RS> > RS> build/msw/*.user
RS> > RS> build/msw/enc_temp_folder/
RS> > RS> build/msw/ipch/
RS> > RS> build/msw/vc*/
RS> > RS> lib/vc*/
RS> >
RS> > Yes, we should have .gitignore, I have pretty much the same locally too
RS> > and I guess everybody else does as well. Although I don't know what are
RS> > enc_temp_folder and ipch directories, I don't have those.
RS>
RS> enc_temp folder is the visual studio autosave/autorecover directory, I
RS> think it's used during edit and continue. ipch is the precompiled header
RS> folder.
The strange thing is that "ipch" doesn't appear in our projects, the PCH
files are generated in different directories. So I wonder if it could be
something specific to your machine (any custom extensions installed?).
Regards,
VZ
RS> On 6/29/2014 7:37 PM, Vadim Zeitlin wrote:
RS> > On Sun, 29 Jun 2014 10:26:13 -0700 'Ray Satiro' via wx-dev wrote:
RS> >
RS> > RS> I use Visual Studio 2010, 2012 and 2013 and I wanted to build
RS> >
RS> > RS> several versions of the wxWidgets library. The file
RS> > RS> docs/msw/install.txt says that a local.props file can be used to
RS> > RS> override the property wxCompilerPrefix, among others.
RS> >
RS> > The thing that it doesn't say is that you actually need to copy
RS> > wx_vcN_wx_setup.props to wx_vcN_local.props and only then modify it. I.e.
RS> > the local.props file needs to contain everything and not just the options
RS> > that you want to change. I agree that it's somewhat counterintuitive and at
RS> > the very least should be explained better.
RS>
RS> Ok. I've never seen it done that way in practice, it strikes me as kind
RS> of unusual.
...
RS> Maybe someone knows the answer to this mystery?
Again, I definitely agree that it would be nice to improve this, but I'm
not an MSBuild expert by any stretch of imagination, so I really don't know
what would be the proper way to do it.
RS> > RS> If you accept these changes please let me know how you want me to
RS> > RS> proceed.
RS> >
RS> > The troublesome thing is that we're going to replace the current projects
RS> > from the ones from this message:
RS> >
RS> > https://groups.google.com/d/msg/wx-dev/WZhS_Jh3zD4/EORznSIw3UYJ
RS> >
RS> > soon, so the patch is not going to apply anyhow. OTOH it is simple enough
RS> > to be reapplied manually to the new projects, I think.
RS>
RS> Ok. I appreciate your need for consolidation. If there's anything I can
RS> do let me know. This is a pretty high traffic mailing list so it's
RS> likely I will unsubscribe when this thread goes stale but you can always
RS> e-mail me directly.
Any tested and working patches to the new unified project files would be
welcome. In fact, even right now testing these new projects would be very
useful too -- please follow up if you do this and tell us how they worked
for you.
RS> > RS> Another thing bothering me was there's no ignore list in the repo for
RS> > RS> the files Visual Studio versions create so I added my own to
RS> > RS> .git/info/exclude (my local gitignore):
RS> > RS> include/wx/msw/setup.h
RS> > RS> build/msw/*_local.props
RS> > RS> build/msw/*.opensdf
RS> > RS> build/msw/*.sdf
RS> > RS> build/msw/*.suo
RS> > RS> build/msw/*.user
RS> > RS> build/msw/enc_temp_folder/
RS> > RS> build/msw/ipch/
RS> > RS> build/msw/vc*/
RS> > RS> lib/vc*/
RS> >
RS> > Yes, we should have .gitignore, I have pretty much the same locally too
RS> > and I guess everybody else does as well. Although I don't know what are
RS> > enc_temp_folder and ipch directories, I don't have those.
RS>
RS> enc_temp folder is the visual studio autosave/autorecover directory, I
RS> think it's used during edit and continue. ipch is the precompiled header
RS> folder.
The strange thing is that "ipch" doesn't appear in our projects, the PCH
files are generated in different directories. So I wonder if it could be
something specific to your machine (any custom extensions installed?).
Regards,
VZ
Artur Wieczorek
Jul 1, 2014, 1:45:12 PM7/1/14
to wx-...@googlegroups.com
W dniu 30.06.2014 05:04, 'Ray Satiro' via wx-dev pisze:
setup.props is practically only about names and naming schemas for
library files and folders. This is a set of elementary user macros
(defining respective prefixes and suffixes) and secondary
macros/properties (being a concatenation of primary macros) which in
fact describe how the the file and folder names are constructed. Because
both kind of macros are closely tied they should be copied as a block to
local.props because they must be modified within the block and with
respect to the rest of the block if user wants to change the way the
names are constructed.
I think implementing additional logic of inheritance, conditional
imports, etc. for this block of user macros and properties wouldn't
bring readable and efficient result.
There is an another story with other properties, not related to the file
names, like eg. list of dependencies. In this case some extra logic
could make sense but the number of these properties is very limited (I
found one) and there is a question if this is worth an effort.
Generally, I think that as for now setup.props should be treated as a
working template of naming schemas which should be rather replaced then
extended by local.props if there is a need to customize the way the
names are constructed.
Regards,
AW
library files and folders. This is a set of elementary user macros
(defining respective prefixes and suffixes) and secondary
macros/properties (being a concatenation of primary macros) which in
fact describe how the the file and folder names are constructed. Because
both kind of macros are closely tied they should be copied as a block to
local.props because they must be modified within the block and with
respect to the rest of the block if user wants to change the way the
names are constructed.
I think implementing additional logic of inheritance, conditional
imports, etc. for this block of user macros and properties wouldn't
bring readable and efficient result.
There is an another story with other properties, not related to the file
names, like eg. list of dependencies. In this case some extra logic
could make sense but the number of these properties is very limited (I
found one) and there is a question if this is worth an effort.
Generally, I think that as for now setup.props should be treated as a
working template of naming schemas which should be rather replaced then
extended by local.props if there is a need to customize the way the
names are constructed.
Regards,
AW
Vadim Zeitlin
Jul 1, 2014, 9:20:16 PM7/1/14
to wx-...@googlegroups.com
On Tue, 01 Jul 2014 19:45:03 +0200 Artur Wieczorek wrote:
AW> Generally, I think that as for now setup.props should be treated as a
AW> working template of naming schemas which should be rather replaced then
AW> extended by local.props if there is a need to customize the way the
AW> names are constructed.
I must say that I'd still prefer to have an as small as possible
local.props, e.g. if I could have just the definitions of the properties I
want to change (typically wxCompilerPrefix, wxCfg, wxVendor), it would be
perfect. But I agree that it's probably not worth the extra effort if it's
not obvious to do.
In fact, if you still have resources/motivation available for working on
this, a more important thing by far would be to bring 3.0 projects in sync
with the trunk ones, notably have a separate custom_build.vcxproj there
too, i.e. backport r76419 to WX_3_0_BRANCH as currently the projects in 3.0
(a) Are very different from the trunk ones.
(b) Don't work for parallel builds.
Ideal would be to update to the new unified projects in the trunk (I'll
try to do this really, really soon) and then update the 3.0 ones to use the
same structure, with just slightly different files (looking at the diff
of build/bakefiles/files.bkl between 3.0 and master, there are not that
many differences yet).
Regards,
VZ
AW> Generally, I think that as for now setup.props should be treated as a
AW> working template of naming schemas which should be rather replaced then
AW> extended by local.props if there is a need to customize the way the
AW> names are constructed.
I must say that I'd still prefer to have an as small as possible
local.props, e.g. if I could have just the definitions of the properties I
want to change (typically wxCompilerPrefix, wxCfg, wxVendor), it would be
perfect. But I agree that it's probably not worth the extra effort if it's
not obvious to do.
In fact, if you still have resources/motivation available for working on
this, a more important thing by far would be to bring 3.0 projects in sync
with the trunk ones, notably have a separate custom_build.vcxproj there
too, i.e. backport r76419 to WX_3_0_BRANCH as currently the projects in 3.0
(a) Are very different from the trunk ones.
(b) Don't work for parallel builds.
Ideal would be to update to the new unified projects in the trunk (I'll
try to do this really, really soon) and then update the 3.0 ones to use the
same structure, with just slightly different files (looking at the diff
of build/bakefiles/files.bkl between 3.0 and master, there are not that
many differences yet).
Regards,
VZ
Artur Wieczorek
Jul 2, 2014, 11:35:01 AM7/2/14
to wx-...@googlegroups.com
> In fact, if you still have resources/motivation available for working on
> this, a more important thing by far would be to bring 3.0 projects in sync
> with the trunk ones, notably have a separate custom_build.vcxproj there
> too, i.e. backport r76419 to WX_3_0_BRANCH as currently the projects in 3.0
>
The attached files contain modified VC11 and VC12 project files for wx
> this, a more important thing by far would be to bring 3.0 projects in sync
> with the trunk ones, notably have a separate custom_build.vcxproj there
> too, i.e. backport r76419 to WX_3_0_BRANCH as currently the projects in 3.0
>
3.0 with separate "custom_build" project to prepare setup.h and
rcdefs.h. Other content is left intact.
Regards,
AW
Vadim Zeitlin
Jul 2, 2014, 12:28:51 PM7/2/14
to wx-...@googlegroups.com
On Wed, 02 Jul 2014 17:34:45 +0200 Artur Wieczorek wrote:
AW> > In fact, if you still have resources/motivation available for working on
AW> > this, a more important thing by far would be to bring 3.0 projects in sync
AW> > with the trunk ones, notably have a separate custom_build.vcxproj there
AW> > too, i.e. backport r76419 to WX_3_0_BRANCH as currently the projects in 3.0
AW> >
AW>
AW> The attached files contain modified VC11 and VC12 project files for wx
AW> 3.0 with separate "custom_build" project to prepare setup.h and
AW> rcdefs.h. Other content is left intact.
Perfect, thanks! I really don't have time for this today but I'll try to
test and commit them tomorrow.
Thanks again!
VZ
AW> > In fact, if you still have resources/motivation available for working on
AW> > this, a more important thing by far would be to bring 3.0 projects in sync
AW> > with the trunk ones, notably have a separate custom_build.vcxproj there
AW> > too, i.e. backport r76419 to WX_3_0_BRANCH as currently the projects in 3.0
AW> >
AW>
AW> The attached files contain modified VC11 and VC12 project files for wx
AW> 3.0 with separate "custom_build" project to prepare setup.h and
AW> rcdefs.h. Other content is left intact.
Perfect, thanks! I really don't have time for this today but I'll try to
test and commit them tomorrow.
Thanks again!
VZ
Vadim Zeitlin
Jul 4, 2014, 7:31:54 AM7/4/14
to wx-...@googlegroups.com
On Wed, 02 Jul 2014 17:34:45 +0200 Artur Wieczorek wrote:
AW> > In fact, if you still have resources/motivation available for working on
AW> > this, a more important thing by far would be to bring 3.0 projects in sync
AW> > with the trunk ones, notably have a separate custom_build.vcxproj there
AW> > too, i.e. backport r76419 to WX_3_0_BRANCH as currently the projects in 3.0
AW> >
AW>
AW> The attached files contain modified VC11 and VC12 project files for wx
AW> 3.0 with separate "custom_build" project to prepare setup.h and
AW> rcdefs.h. Other content is left intact.
Thanks again, I've committed these patches to 3.0 branch now. I still have
to apply your patches to the trunk projects, I'll try to do it soon too.
Regards,
VZ
AW> > In fact, if you still have resources/motivation available for working on
AW> > this, a more important thing by far would be to bring 3.0 projects in sync
AW> > with the trunk ones, notably have a separate custom_build.vcxproj there
AW> > too, i.e. backport r76419 to WX_3_0_BRANCH as currently the projects in 3.0
AW> >
AW>
AW> The attached files contain modified VC11 and VC12 project files for wx
AW> 3.0 with separate "custom_build" project to prepare setup.h and
AW> rcdefs.h. Other content is left intact.
Thanks again, I've committed these patches to 3.0 branch now. I still have
to apply your patches to the trunk projects, I'll try to do it soon too.
Regards,
VZ
Ray Satiro
Jul 16, 2014, 1:18:02 PM7/16/14
to wx-...@googlegroups.com
On 6/30/2014 7:55 AM, Vadim Zeitlin wrote:
> On Sun, 29 Jun 2014 23:04:14 -0400 'Ray Satiro' via wx-dev wrote:
>
> RS> > RS> If you accept these changes please let me know how you want me to
> RS> > RS> proceed.
> RS> >
> RS> > The troublesome thing is that we're going to replace the current projects
> RS> > from the ones from this message:
> RS> >
> RS> > https://groups.google.com/d/msg/wx-dev/WZhS_Jh3zD4/EORznSIw3UYJ
> RS> >
> RS> > soon, so the patch is not going to apply anyhow. OTOH it is simple enough
> RS> > to be reapplied manually to the new projects, I think.
> RS>
> RS> Ok. I appreciate your need for consolidation. If there's anything I can
> RS> do let me know. This is a pretty high traffic mailing list so it's
> RS> likely I will unsubscribe when this thread goes stale but you can always
> RS> e-mail me directly.
>
> Any tested and working patches to the new unified project files would be
> welcome. In fact, even right now testing these new projects would be very
> useful too -- please follow up if you do this and tell us how they worked
> for you.
I tried the project files referenced in that thread in Visual Studio
> On Sun, 29 Jun 2014 23:04:14 -0400 'Ray Satiro' via wx-dev wrote:
>
> RS> > RS> If you accept these changes please let me know how you want me to
> RS> > RS> proceed.
> RS> >
> RS> > The troublesome thing is that we're going to replace the current projects
> RS> > from the ones from this message:
> RS> >
> RS> > https://groups.google.com/d/msg/wx-dev/WZhS_Jh3zD4/EORznSIw3UYJ
> RS> >
> RS> > soon, so the patch is not going to apply anyhow. OTOH it is simple enough
> RS> > to be reapplied manually to the new projects, I think.
> RS>
> RS> Ok. I appreciate your need for consolidation. If there's anything I can
> RS> do let me know. This is a pretty high traffic mailing list so it's
> RS> likely I will unsubscribe when this thread goes stale but you can always
> RS> e-mail me directly.
>
> Any tested and working patches to the new unified project files would be
> welcome. In fact, even right now testing these new projects would be very
> useful too -- please follow up if you do this and tell us how they worked
> for you.
2010 SP1, 2012.4 and 2013 CTP1. I had to copy the setup0 to setup.h
first and then the respective solution built fine in each using Debug
Win32. I built using master (b7e1443 20140715). In order to get
Intellisense to work properly (it was confused on some of the
preprocessor defines) I had to close out the solution and reopen it
after I successfully built (that is related to Visual Studio, not your
project).
You can use a generic solution file the same way you have generic
project files. Use Artur's VS2010 solution file for VS2012 and VS2013 as
well instead of three separate solutions, since they are all basically
the same and later versions of Visual Studio can read version 10 files
aka format version 11.00 (which is calculated as n - 1 or 11 - 1 = 10,
don't ask me why ).
Since you are building with the appropriate toolsets (eg VS2012 built
using VC12) I have replaced wxCompilerPrefix in the setup props with
<wxCompilerPrefix>vc$(PlatformToolsetVersion)</wxCompilerPrefix>
That gives me the same output I had with the old project files. I'm
hesitant to copy the setup.props to a local because if other setup
properties change when I pull from git I'd rather a merge conflict in my
setup than it going by unnoticed and my local props overriding those
settings (like you bump version number and my local still has old
version). Also I think I might hard link setup.h to setup0.h so I don't
have to worry about changes there either, since I don't modify anything
in it anyway.
Ray Satiro
Jul 31, 2014, 9:09:34 PM7/31/14
to wx-...@googlegroups.com
On 7/16/2014 1:17 PM, 'Ray Satiro' via wx-dev wrote:
> I tried the project files referenced in that thread in Visual Studio
> 2010 SP1, 2012.4 and 2013 CTP1. I had to copy the setup0 to setup.h
> first and then the respective solution built fine in each using Debug
> Win32. I built using master (b7e1443 20140715). In order to get
> Intellisense to work properly (it was confused on some of the
> preprocessor defines) I had to close out the solution and reopen it
> after I successfully built (that is related to Visual Studio, not your
> project).
I am going to unsubscribe soon because this list is pretty high volume.
> I tried the project files referenced in that thread in Visual Studio
> 2010 SP1, 2012.4 and 2013 CTP1. I had to copy the setup0 to setup.h
> first and then the respective solution built fine in each using Debug
> Win32. I built using master (b7e1443 20140715). In order to get
> Intellisense to work properly (it was confused on some of the
> preprocessor defines) I had to close out the solution and reopen it
> after I successfully built (that is related to Visual Studio, not your
> project).
It has been very helpful. If you need any more help testing Visual
Studio 2010+ build files you can contact me directly. Currently I'm
using Artur's wx_vc_v2.zip with master (960eedb 20140727).
Thanks
Reply all
Reply to author
Forward
0 new messages