Using wxwidgets.props
500 views
Skip to first unread message
PB
May 25, 2020, 9:47:07 AM5/25/20
to wx-users
Hi,
Is wxwidgets.props assumed to be used mostly with the official binaries or is it supposed to be simple yet versatile and supersede including the MSVC-specific setup.h?
Seeing the recent wxwidgets.props-related commit, I have tried using wxwidgets.props (knowing nothing about MSVS properties system) with self-built binaries (I have both static and dynamic ones). As I prefer my paths not to be hard-coded, based on the comment in wxwidgets.props, I edited the .vcxproj file directly, copy-pasting
<Import Project="$(WXWIN)\wxwidgets.props"> right after <Import Project="$(VCTargetsPath)\Microsoft.Cpp.Default.props" />
However, MSVS failed to load the project, complaining about syntax error. I noticed that a closing “ /” was missing before “>”, so I added it. After that, the project loaded successfully but when trying to build it, I ended with
>D:\Dev\Desktop\!Lib\wxWidgets-GIT\wxwidgets.props(111,5): error : wxWidgets libraries not found under "D:\Dev\Desktop\!Lib\wxWidgets-GIT\lib".
My bad, I guess I added the import too early before some required properties were evaluated. I moved the import line to the end of the .vcxproj file and the project built fine. However, when I tried to launch the built program, it complained about wxWidgets DLLs not found. I understand that the dynamic build is the default, but I was not able to figure out how to tell MSVS that I want to use the static build of wxWidgets.
So, is it possible to somehow easily set the build settings ($wxXYZ) per project and per configuration (analogically to defining e.g. WXUSINGDLL or wxCFG when using MSVC-specific setup.h) inside MSVS in the project settings; or, when using the .props file all customizations must be done via including a custom .props file (which seems quite powerful but overly complicated compared to setting the defines, but perhaps it's just me)?
Thanks,
PB
Vadim Zeitlin
May 25, 2020, 10:35:01 AM5/25/20
to wx-u...@googlegroups.com
On Mon, 25 May 2020 06:47:07 -0700 (PDT) PB wrote:
P> Is *wxwidgets.props* assumed to be used mostly with the official binaries
P> or is it supposed to be simple yet versatile and supersede including the
P> MSVC-specific *setup.h*?
I hope to make it usable in all situations. Using msvc/wx/setup.h was a
step in the right direction, but it's still not simple enough, as you still
have to specify the library paths and vc14x toolsets API compatibility
means that you may need, or not, to additionally add wxMSVC_ABI_VERSION
&c definitions which is clearly too complicated.
The goal is for the current instructions for setting up wx applications to
work, i.e. "just add wxwidgets.props to your project and that's it". But
unfortunately, we're not quite there yet and I believe that we need another
.props file, something like wxapp.props, that would be copied into the
program own directory and serve several purposes:
1. It will contain <Import Project="$(WXWIN)\wxwidgets.props"/> or, rather,
conditional import -- and then verify that it succeeded and give a
helpful error message if it hasn't.
2. It will allow predefining some variables to select wx binaries to use
if more than one set is available.
3. It will (optionally?) copy wx DLLs to the project output directory to
allow running the program without fiddling with the PATH.
It seems a bit stupid to have 2 properties files, but at least (1) can't be
easily done otherwise.
P> Seeing the recent* wxwidgets.props*-related commit, I have tried using
P> *wxwidgets.props* (knowing nothing about MSVS properties system) with
P> self-built binaries (I have both static and dynamic ones). As I prefer my
P> paths not to be hard-coded, based on the comment in *wxwidgets.props*, I
P> edited the *.vcxproj* file directly, copy-pasting
P>
P> <Import Project="$(WXWIN)\wxwidgets.props"> right after <Import
P> Project="$(VCTargetsPath)\Microsoft.Cpp.Default.props" />
P>
P> However, MSVS failed to load the project, complaining about syntax error. I
P> noticed that a closing “ /” was missing before “>”, so I added it.
Oops, thanks, fixed (by applying your PR).
P> After that, the project loaded successfully but when trying to build it,
P> I ended with
P>
P> > >D:\Dev\Desktop\!Lib\wxWidgets-GIT\wxwidgets.props(111,5): error :
P> > wxWidgets libraries not found under "D:\Dev\Desktop\!Lib\wxWidgets-GIT\lib".
P> >
P> My bad, I guess I added the import too early before some required
P> properties were evaluated.
I don't really understand what happened here, i.e. what exactly is wrong?
P> I moved the import line to the end of the *.vcxproj* file and the
P> project built fine. However, when I tried to launch the built program,
P> it complained about wxWidgets DLLs not found.
FWIW I always dealt with this problem by just setting a custom PATH to
include the DLLs directory, but other projects seem to avoid the problem by
copying the DLLs to the project directory instead using MSBuild special
ReferenceCopyLocalPaths tag. I hesitate to do this unconditionally because
wx DLLs are not exactly small and copying them to all projects could eat
quite a lot of disk space, but OTOH this could clearly help people.
P> I understand that the dynamic build is the default, but I was not able
P> to figure out how to tell MSVS that I want to use the static build of
P> wxWidgets.
Right now it isn't possible to do this. I've decided to prioritize using
DLLs if both are available because the official binaries are DLLs and also
because linking with them should be faster (if only because the generated
binaries are smaller).
P> So, is it possible to somehow easily set the build settings ($wxXYZ) per
P> project and per configuration (analogically to defining e.g. WXUSINGDLL or
P> wxCFG when using MSVC-specific *setup.h*) inside MSVS in the project
P> settings; or, when using the .props file all customizations must be done
P> via including a custom *.props* file (which seems quite powerful but overly
P> complicated compared to setting the defines, but perhaps it's just me)?
I think it could be possible to define more of "General Properties" shown
on the "General" page of the "Property Pages" MSVS dialog, i.e. it ought to
be possible to add "wxWidgets configuration to use" there, but I don't know
how to do this.
So my idea is to indeed have the wxapp.props file mentioned above. If
anybody knows more about this and/or sees better way to do it, I'd very
much like to hear about it!
Thanks,
VZ
--
TT-Solutions: wxWidgets consultancy and technical support
http://www.tt-solutions.com/
P> Is *wxwidgets.props* assumed to be used mostly with the official binaries
P> or is it supposed to be simple yet versatile and supersede including the
P> MSVC-specific *setup.h*?
I hope to make it usable in all situations. Using msvc/wx/setup.h was a
step in the right direction, but it's still not simple enough, as you still
have to specify the library paths and vc14x toolsets API compatibility
means that you may need, or not, to additionally add wxMSVC_ABI_VERSION
&c definitions which is clearly too complicated.
The goal is for the current instructions for setting up wx applications to
work, i.e. "just add wxwidgets.props to your project and that's it". But
unfortunately, we're not quite there yet and I believe that we need another
.props file, something like wxapp.props, that would be copied into the
program own directory and serve several purposes:
1. It will contain <Import Project="$(WXWIN)\wxwidgets.props"/> or, rather,
conditional import -- and then verify that it succeeded and give a
helpful error message if it hasn't.
2. It will allow predefining some variables to select wx binaries to use
if more than one set is available.
3. It will (optionally?) copy wx DLLs to the project output directory to
allow running the program without fiddling with the PATH.
It seems a bit stupid to have 2 properties files, but at least (1) can't be
easily done otherwise.
P> Seeing the recent* wxwidgets.props*-related commit, I have tried using
P> *wxwidgets.props* (knowing nothing about MSVS properties system) with
P> self-built binaries (I have both static and dynamic ones). As I prefer my
P> paths not to be hard-coded, based on the comment in *wxwidgets.props*, I
P> edited the *.vcxproj* file directly, copy-pasting
P>
P> <Import Project="$(WXWIN)\wxwidgets.props"> right after <Import
P> Project="$(VCTargetsPath)\Microsoft.Cpp.Default.props" />
P>
P> However, MSVS failed to load the project, complaining about syntax error. I
P> noticed that a closing “ /” was missing before “>”, so I added it.
Oops, thanks, fixed (by applying your PR).
P> After that, the project loaded successfully but when trying to build it,
P> I ended with
P>
P> > >D:\Dev\Desktop\!Lib\wxWidgets-GIT\wxwidgets.props(111,5): error :
P> > wxWidgets libraries not found under "D:\Dev\Desktop\!Lib\wxWidgets-GIT\lib".
P> >
P> My bad, I guess I added the import too early before some required
P> properties were evaluated.
I don't really understand what happened here, i.e. what exactly is wrong?
P> I moved the import line to the end of the *.vcxproj* file and the
P> project built fine. However, when I tried to launch the built program,
P> it complained about wxWidgets DLLs not found.
FWIW I always dealt with this problem by just setting a custom PATH to
include the DLLs directory, but other projects seem to avoid the problem by
copying the DLLs to the project directory instead using MSBuild special
ReferenceCopyLocalPaths tag. I hesitate to do this unconditionally because
wx DLLs are not exactly small and copying them to all projects could eat
quite a lot of disk space, but OTOH this could clearly help people.
P> I understand that the dynamic build is the default, but I was not able
P> to figure out how to tell MSVS that I want to use the static build of
P> wxWidgets.
Right now it isn't possible to do this. I've decided to prioritize using
DLLs if both are available because the official binaries are DLLs and also
because linking with them should be faster (if only because the generated
binaries are smaller).
P> So, is it possible to somehow easily set the build settings ($wxXYZ) per
P> project and per configuration (analogically to defining e.g. WXUSINGDLL or
P> wxCFG when using MSVC-specific *setup.h*) inside MSVS in the project
P> settings; or, when using the .props file all customizations must be done
P> via including a custom *.props* file (which seems quite powerful but overly
P> complicated compared to setting the defines, but perhaps it's just me)?
I think it could be possible to define more of "General Properties" shown
on the "General" page of the "Property Pages" MSVS dialog, i.e. it ought to
be possible to add "wxWidgets configuration to use" there, but I don't know
how to do this.
So my idea is to indeed have the wxapp.props file mentioned above. If
anybody knows more about this and/or sees better way to do it, I'd very
much like to hear about it!
Thanks,
VZ
--
TT-Solutions: wxWidgets consultancy and technical support
http://www.tt-solutions.com/
PB
May 25, 2020, 1:07:40 PM5/25/20
to wx-users
Thanks for the quick reply and sorry for botching the PR.
Regarding the DLL availability when debugging a wxWidgets application. As you wrote, what I do is modify MSVS project Configuration Properties / Debugging, where I set Environment to something like
PATH=$(WXWIN)\lib\vc_dll and Merge Environment to Yes. This will ensure that the DLLs are available without modifying the user's PATH variable or copying the DLLs. I think this could be perhaps also set with properties but it has at least one disadvantage: some less experienced programmers may be surprised when they distribute their program (or just launch it outside the IDE) and it won't run because it does not have the wxWidgets DLLs available.P> > >D:\Dev\Desktop\!Lib\wxWidgets-GIT\wxwidgets.props(111,5): error :
P> > wxWidgets libraries not found under "D:\Dev\Desktop\!Lib\wxWidgets-GIT\lib".
P> My bad, I guess I added the import too early before some required
P> properties were evaluated.
P> > wxWidgets libraries not found under "D:\Dev\Desktop\!Lib\wxWidgets-GIT\lib".
P> My bad, I guess I added the import too early before some required
P> properties were evaluated.
VZ> I don't really understand what happened here, i.e. what exactly is wrong?
To me it looks as if the system could not figure out whether I am using a static or dynamic wxWidgets build, so the part of the path which should be either "\vc_lib" or "\vc_dll" ended being empty.
Regarding the usefulness of properties. I am afraid the property system is quite complicated and it could be possible that its main target audience, i.e., people having trouble setting-up a wxWidgets MSVS project, will find customizing it too difficult. I am quite active on a wxForum and it seems that many people struggle with very basic things even I could figure out. But I guess such people will not customize their projects much and the defaults will be good enough.
BTW, it looks as if the wxwidgets.props file does not modify Include directories for Resources: Is it by design? I suppose the resource file itself cannot be somehow added via .props file and the #include "wx/msw/wx.rc" still needs to be added by the programmer to the application .rc file manually...
Regards,
PB
Vadim Zeitlin
May 25, 2020, 1:24:04 PM5/25/20
to wx-u...@googlegroups.com
On Mon, 25 May 2020 10:07:39 -0700 (PDT) PB wrote:
P> Thanks for the quick reply and sorry for botching the PR.
Oops, I totally failed to notice this typo neither...
P> Regarding the DLL availability when debugging a wxWidgets application. As
P> you wrote, what I do is modify MSVS project *Configuration Properties* /
P> Debugging, where I set Environment to something like
P> PATH=$(WXWIN)\lib\vc_dll and *Merge Environment* to Yes. This will ensure
P> that the DLLs are available without modifying the user's PATH variable or
P> copying the DLLs. I think this could be perhaps also set with properties
I don't think so because AFAIK these options are not stored in the project
files but rather local-only MSVS files.
P> P> > >D:\Dev\Desktop\!Lib\wxWidgets-GIT\wxwidgets.props(111,5): error :
P> P> > wxWidgets libraries not found under
P> "D:\Dev\Desktop\!Lib\wxWidgets-GIT\lib".
P> P> My bad, I guess I added the import too early before some required
P> P> properties were evaluated.
P> VZ> I don't really understand what happened here, i.e. what exactly is
P> wrong?
P> To me it looks as if the system could not figure out whether I am using a
P> static or dynamic wxWidgets build, so the part of the path which should be
P> either "\vc_lib" or "\vc_dll" ended being empty.
Ah, so "!Lib" part is normal? This is what seemed the most surprising to
me. In any case, it looks like the error message is misleading, because
it's supposed to really just give the path to the "lib" directory, but I
am not sure how to improve it.
But the real question is why weren't the existing libraries found. It
would be interesting if you could add a <Warning> (or <Message>, but you
need to use Priority="High" with this one to see it during the build at all
with the default verbosity options) to output the value of the argument of
"Exists()" in the "When" tag that was supposed to match your libraries.
Clearly some part of it must not have been expanded correctly, but I don't
know which one.
P> Regarding the usefulness of properties. I am afraid the property system is
P> quite complicated and it could be possible that its main target audience,
P> i.e., people having trouble setting-up a wxWidgets MSVS project, will find
P> customizing it too difficult.
The idea would be to tell people: copy wxapp.props to your project
directory and include it in your project. And it would work out of the box
using $(WXWIN) but could also be customized if necessary.
The main problem I see is that there would be 2 ways to make things work,
as you could also include $(WXWIN)/wxwidgets.props directly. And this is
one too many... But I don't know what else could we do.
P> I am quite active on a wxForum and it seems that many people struggle
P> with very basic things even I could figure out.
Yes, this is what I see too (not necessarily on wxForum).
P> But I guess such people will not customize their projects much and the
P> defaults will be good enough.
Yes, but there will be more advanced users who will want to customize
them as well and it'd be nice if the same solution could work for both of
them. We could tell such advanced users to write their wxapp.props file
themselves (this is what I actually do in my existing projects), but this
seems a bit unhelpful.
P> BTW, it looks as if the *wxwidgets.props* file does not modify Include
P> directories for Resources: Is it by design?
No, it's supposed to modify them, see ResourceCompile tags. If this
doesn't work for you, check that you use "%(AdditionalIncludeDirectories)"
at the end of your custom options or, equivalently, "Inherit" checkbox is
checked.
P> I suppose the resource file itself cannot be somehow added via *.props*
P> file and the #include "wx/msw/wx.rc" still needs to be added by the
P> programmer to the application *.rc* file manually...
Yes, but then any application will want to have its own .rc file anyhow,
if only for the icon, so we can't really get rid of it.
Thanks again for testing this, your feedback is much appreciated,
P> Thanks for the quick reply and sorry for botching the PR.
Oops, I totally failed to notice this typo neither...
P> Regarding the DLL availability when debugging a wxWidgets application. As
P> you wrote, what I do is modify MSVS project *Configuration Properties* /
P> Debugging, where I set Environment to something like
P> PATH=$(WXWIN)\lib\vc_dll and *Merge Environment* to Yes. This will ensure
P> that the DLLs are available without modifying the user's PATH variable or
P> copying the DLLs. I think this could be perhaps also set with properties
I don't think so because AFAIK these options are not stored in the project
files but rather local-only MSVS files.
P> P> > >D:\Dev\Desktop\!Lib\wxWidgets-GIT\wxwidgets.props(111,5): error :
P> P> > wxWidgets libraries not found under
P> "D:\Dev\Desktop\!Lib\wxWidgets-GIT\lib".
P> P> My bad, I guess I added the import too early before some required
P> P> properties were evaluated.
P> VZ> I don't really understand what happened here, i.e. what exactly is
P> wrong?
P> To me it looks as if the system could not figure out whether I am using a
P> static or dynamic wxWidgets build, so the part of the path which should be
P> either "\vc_lib" or "\vc_dll" ended being empty.
Ah, so "!Lib" part is normal? This is what seemed the most surprising to
me. In any case, it looks like the error message is misleading, because
it's supposed to really just give the path to the "lib" directory, but I
am not sure how to improve it.
But the real question is why weren't the existing libraries found. It
would be interesting if you could add a <Warning> (or <Message>, but you
need to use Priority="High" with this one to see it during the build at all
with the default verbosity options) to output the value of the argument of
"Exists()" in the "When" tag that was supposed to match your libraries.
Clearly some part of it must not have been expanded correctly, but I don't
know which one.
P> Regarding the usefulness of properties. I am afraid the property system is
P> quite complicated and it could be possible that its main target audience,
P> i.e., people having trouble setting-up a wxWidgets MSVS project, will find
P> customizing it too difficult.
The idea would be to tell people: copy wxapp.props to your project
directory and include it in your project. And it would work out of the box
using $(WXWIN) but could also be customized if necessary.
The main problem I see is that there would be 2 ways to make things work,
as you could also include $(WXWIN)/wxwidgets.props directly. And this is
one too many... But I don't know what else could we do.
P> I am quite active on a wxForum and it seems that many people struggle
P> with very basic things even I could figure out.
Yes, this is what I see too (not necessarily on wxForum).
P> But I guess such people will not customize their projects much and the
P> defaults will be good enough.
Yes, but there will be more advanced users who will want to customize
them as well and it'd be nice if the same solution could work for both of
them. We could tell such advanced users to write their wxapp.props file
themselves (this is what I actually do in my existing projects), but this
seems a bit unhelpful.
P> BTW, it looks as if the *wxwidgets.props* file does not modify Include
P> directories for Resources: Is it by design?
No, it's supposed to modify them, see ResourceCompile tags. If this
doesn't work for you, check that you use "%(AdditionalIncludeDirectories)"
at the end of your custom options or, equivalently, "Inherit" checkbox is
checked.
P> I suppose the resource file itself cannot be somehow added via *.props*
P> file and the #include "wx/msw/wx.rc" still needs to be added by the
P> programmer to the application *.rc* file manually...
Yes, but then any application will want to have its own .rc file anyhow,
if only for the icon, so we can't really get rid of it.
Thanks again for testing this, your feedback is much appreciated,
PB
May 25, 2020, 2:08:22 PM5/25/20
to wx-users
Thanks again for the quick reply.
P> BTW, it looks as if the *wxwidgets.props* file does not modify Include
P> directories for Resources: Is it by design?
VZ> No, it's supposed to modify them, see ResourceCompile tags. If this....
Sorry, it works and that was just being me stupid again. It's just that to me, not seeing any modified settings at all in MSVS project properties even when checking the evaluated ones (everything being done invisibly) seems a bit unnatural and seeing the Additional Include directories totally empty confused me. Sorry for all the noise.
Regards,
PB
Vadim Zeitlin
May 25, 2020, 4:28:39 PM5/25/20
to wx-u...@googlegroups.com
On Mon, 25 May 2020 11:08:22 -0700 (PDT) PB wrote:
P> Thanks again for the quick reply.
P>
P> P> BTW, it looks as if the *wxwidgets.props* file does not modify Include
P> > P> directories for Resources: Is it by design?
P> > VZ> No, it's supposed to modify them, see ResourceCompile tags. If this....
P> >
P> Sorry, it works and that was just being me stupid again. It's just that to
P> me, not seeing any modified settings at all in MSVS project properties even
P> when checking the evaluated ones (everything being done invisibly)
This is probably not very important, but you're definitely supposed to see
the wx paths in the expanded/evaluated value when opening the dialog from
the field popup. Another way to see the options being actually used is to
look at the "Command line" in the properties window where the options
should definitely appear (and if they don't, this means that they're not
used).
Regards,
P> Thanks again for the quick reply.
P>
P> P> BTW, it looks as if the *wxwidgets.props* file does not modify Include
P> > P> directories for Resources: Is it by design?
P> > VZ> No, it's supposed to modify them, see ResourceCompile tags. If this....
P> >
P> Sorry, it works and that was just being me stupid again. It's just that to
P> me, not seeing any modified settings at all in MSVS project properties even
P> when checking the evaluated ones (everything being done invisibly)
This is probably not very important, but you're definitely supposed to see
the wx paths in the expanded/evaluated value when opening the dialog from
the field popup. Another way to see the options being actually used is to
look at the "Command line" in the properties window where the options
should definitely appear (and if they don't, this means that they're not
used).
Regards,
PB
May 26, 2020, 4:11:25 AM5/26/20
to wx-users
On Monday, May 25, 2020 at 10:28:39 PM UTC+2, Vadim Zeitlin wrote:
VZ> This is probably not very important, but you're definitely supposed to see
VZ>the wx paths in the expanded/evaluated value when opening the dialog from
VZ>the field popup. Another way to see the options being actually used is to
VZ>look at the "Command line" in the properties window where the options
VZ>should definitely appear (and if they don't, this means that they're not
If I add wxwidgets.props manually to the.vcxproj file (at its very end, right before </Project>), everything builds but the settings are not reflected in the project properties settings, surprisingly including the full command line display:
C++ Compiler Includes (please notice that all $(wxXYZ) values look correct), %(AdditionalIncludeDirectories) is not in the macros:
C++ Compiler Command Line (please notice no wxWidgets or defines or includes are there): https://imgur.com/a/FIbhVNn
Linker Command Line: https://imgur.com/a/L6tO8RW
When I add wxwidgets.props via Property Manager's Add Existing Property Sheet, the values are displayed, e.g., C/C++ / General / Additional Include Directories contains $(MSBuildThisFileDirectory)include\msvc;$(MSBuildThisFileDirectory)include and there is macro %(AdditionalIncludeDirectories) containing the two wxWidgets include directories.
So once again I am probably doing something wrong, i.e., adding the .props file manually in the wrong place(s). Sorry for wasting your time. I will just stick to the simple good old ways. ;)
Regards,
PB
Mike Airey
May 26, 2020, 8:34:53 AM5/26/20
to wx-users
Hi PB,
Apologies for barging in, I saw your post and thought about vcpkg (https://docs.microsoft.com/en-us/cpp/build/vcpkg). If you're developing with wxWidgets in Visual Studio on Windows it can be quite helpful, or at least I found it to be. All depends on your specific situation I suppose, but it might be worth a try? Again please disregard if you have already evaluated and dismissed vcpkg or are not interested :)
Cheers,
Mike
Vadim Zeitlin
May 26, 2020, 10:13:57 AM5/26/20
to wx-u...@googlegroups.com
On Tue, 26 May 2020 01:11:24 -0700 (PDT) PB wrote:
P> If I add *wxwidgets.props* manually to the*.vcxproj* file (at its very end,
P> right before </Project>), everything builds but the settings are not
P> reflected in the project properties settings, surprisingly including the
P> full command line display:
So it looks like the order in the project file does matter... FWIW I add
my import tag inside <ImportGroup Label="PropertySheets"> which I add after
Microsoft.Cpp.props import. I.e. it looks like this:
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.props" />
<ImportGroup Label="ExtensionSettings">
</ImportGroup>
<ImportGroup Label="PropertySheets">
<Import Project="3rdparty\wx\wxWidgets.props" />
</ImportGroup>
<ImportGroup Condition="'$(Configuration)|$(Platform)'=='Release|Win32'" Label="PropertySheets">
<Import Project="$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props" Condition="exists('$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props')" Label="LocalAppDataPlatform" />
</ImportGroup>
...
(in this particular project, wx is a submodule under 3rdparty).
If you add the property sheet from the GUI, it gets added to each
individual ImportGroup corresponding to the Configuration+Platform
combination, which doesn't make much sense to me, as I want to use it
unconditionally, so I just do the closest thing to what the IDE does.
P> When I add *wxwidgets.props* via Property Manager's *Add Existing Property
P> Sheet*, the values are displayed, e.g., *C/C++ / General / Additional
P> Include Directories* contains $(MSBuildThisFileDirectory)include\msvc;$(MSBuildThisFileDirectory)include
P> and there is macro %(AdditionalIncludeDirectories) containing the two
P> wxWidgets include directories.
Yes, this is what I see with my "manual" method too.
P> So once again I am probably doing something wrong, i.e., adding the *.props*
P> file manually in the wrong place(s). Sorry for wasting your time. I will
P> just stick to the simple good old ways. ;)
I really like the idea of using property sheets, it's the least intrusive
and most flexible (e.g. nothing needs to be done when upgrading wx) way. I
just wish there were better documentation of all this stuff.
P> If I add *wxwidgets.props* manually to the*.vcxproj* file (at its very end,
P> right before </Project>), everything builds but the settings are not
P> reflected in the project properties settings, surprisingly including the
P> full command line display:
So it looks like the order in the project file does matter... FWIW I add
my import tag inside <ImportGroup Label="PropertySheets"> which I add after
Microsoft.Cpp.props import. I.e. it looks like this:
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.props" />
<ImportGroup Label="ExtensionSettings">
</ImportGroup>
<ImportGroup Label="PropertySheets">
<Import Project="3rdparty\wx\wxWidgets.props" />
</ImportGroup>
<ImportGroup Condition="'$(Configuration)|$(Platform)'=='Release|Win32'" Label="PropertySheets">
<Import Project="$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props" Condition="exists('$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props')" Label="LocalAppDataPlatform" />
</ImportGroup>
...
(in this particular project, wx is a submodule under 3rdparty).
If you add the property sheet from the GUI, it gets added to each
individual ImportGroup corresponding to the Configuration+Platform
combination, which doesn't make much sense to me, as I want to use it
unconditionally, so I just do the closest thing to what the IDE does.
P> When I add *wxwidgets.props* via Property Manager's *Add Existing Property
P> Sheet*, the values are displayed, e.g., *C/C++ / General / Additional
P> Include Directories* contains $(MSBuildThisFileDirectory)include\msvc;$(MSBuildThisFileDirectory)include
P> and there is macro %(AdditionalIncludeDirectories) containing the two
P> wxWidgets include directories.
Yes, this is what I see with my "manual" method too.
P> So once again I am probably doing something wrong, i.e., adding the *.props*
P> file manually in the wrong place(s). Sorry for wasting your time. I will
P> just stick to the simple good old ways. ;)
I really like the idea of using property sheets, it's the least intrusive
and most flexible (e.g. nothing needs to be done when upgrading wx) way. I
just wish there were better documentation of all this stuff.
PB
May 27, 2020, 6:43:25 AM5/27/20
to wx-users
Hi Mike,
I am aware of vcpgk; however, it does not fit my usage scenario. I tend to play with wxWidgets a bit, sometimes rapidly switching between different versions, configurations, IDEs, and compilers and so I find it easier to set-up the projects using it myself.
TBH, I am not an advanced user yet I have never found using wxWidgets difficult (I am WIndows only though). And with MSVC with its autolinking feature it is even easier. All you need to is to set the compiler include and linker library folders, and perhaps some preprocessor defines; just like with any other compiled C++ library.
The only difference may be that two different include folders are needed and the linker folder name has 4 parts, where each can vary independently of the others. But all this is clearly documented and should be easy to follow for a (n aspiring) C++ programmer...
Regards,
PB
Mike Airey
May 27, 2020, 9:20:40 AM5/27/20
to wx-u...@googlegroups.com
Hi PB,
Cool, no worries. I've always been more on the .NETty side of things so vcpkg with its abstracting away of a lot of the C++ build tooling was a good solution for me; glad to hear you've at least heard of it :)
Cheers,
Mike
--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.
To unsubscribe, send email to wx-users+u...@googlegroups.com
or visit http://groups.google.com/group/wx-users
---
You received this message because you are subscribed to a topic in the Google Groups "wx-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/wx-users/NsBx1h7xrYM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to wx-users+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/wx-users/7f70f1e5-3417-475f-b809-315da61e13f2%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages