Multi-platform vcproj produces invalid CMakeLists.txt
Visual Studio .vc[x]proj to CMakeLists.txt (make, Ninja ...) enabler
Status: Alpha
Brought to you by:
andim2
Menu
▾
▴
#1 Multi-platform vcproj produces invalid CMakeLists.txt
closed-fixed
nobody
None
5
2012-09-23
2010-09-14
No
vcproj files containing multiple platforms (win32, x64) produce invalid CMakeLists.txt files. cmake will encounter multiple occurrences of add_library(<projectname>) or add_executable(<projectname>) calls in this case. See attached projects.
Discussion
Multi-platform test projects
Ah, interesting to see that we have a problem exactly where CMake itself also has one ;)
(AFAIK CMake doesn't support creating multi-arch .vcproj files)
One could say that vcproj2cmake.rb/vc8_get_config_name() has a problem.
Since it simply splits the configuration name into piped elements, it will end up with Debug/Release only.
However that was actually very _intentional_ in the original vcproj2cmake.rb script, I'm sure
(since CMake itself works with "Debug"/"Release" CMAKE_BUILD_TYPE strings, thus it needs to match).
Flattening the "Debug|Win64" into "Debug_Win64" to get distinct configuration names thus would not be useful at all, since it would then fail to match the standard CMake names.
Rather, I think we need to maintain the arch string as a separate config setting and add custom
if(V2C_CONFIGURATION_ARCH STREQUAL "Win64")
lines around the Debug / Release sections.
Or some such.
Of course then the question would be how to most fittingly guarantee sane default behaviour (i.e., e.g. have "Win32" as the default setting, so that a standard build run _will_ work properly instead of simply doing nothing).
I'm afraid we're now at a point where it would be _very_ beneficial to have full separation between vc8 parsing and later CMake syntax generation, since we would then _first_ collect the full list of configuration architectures and _then_ know which ones we have and thus which one to set() as the default.
I'll try to come up with a good solution to this, but no promises :-P
Thanks for your input! (and the very nice test project content) Any other issues?
I hope that vcproj2cmake already managed to be useful despite this issue...
> Ah, interesting to see that we have a problem exactly where CMake itself
> also has one ;)
> (AFAIK CMake doesn't support creating multi-arch .vcproj files)
Absolutely, but if you use CMake as your source, you can tell it to create 32 or 64 bit vcprojs, which eliminates that problem for automated environments. It's just inconvenient for conversions.
> One could say that vcproj2cmake.rb/vc8_get_config_name() has a problem.
> Since it simply splits the configuration name into piped elements, it will
> end up with Debug/Release only.
> However that was actually very _intentional_ in the original
> vcproj2cmake.rb script, I'm sure
> (since CMake itself works with "Debug"/"Release" CMAKE_BUILD_TYPE strings,
> thus it needs to match).
Very likely so. Even so, VS gives you the option of other configurations as well, so I'm not entirely sure how those should be mapped. That's probably for later anyway, since it doesn't cause cmake to fail.
> Flattening the "Debug|Win64" into "Debug_Win64" to get distinct
> configuration names thus would not be useful at all, since it would then
> fail to match the standard CMake names.
> Rather, I think we need to maintain the arch string as a separate config
> setting and add custom
> if(V2C_CONFIGURATION_ARCH STREQUAL "Win64")
> lines around the Debug / Release sections.
> Or some such.
Would be preferred. I had hacked the script by ignoring everything that wasn't Win32 by the way.
> Of course then the question would be how to most fittingly guarantee sane
> default behaviour (i.e., e.g. have "Win32" as the default setting, so that
> a standard build run _will_ work properly instead of simply doing
> nothing).
> I'm afraid we're now at a point where it would be _very_ beneficial to
> have full separation between vc8 parsing and later CMake syntax generation,
> since we would then _first_ collect the full list of configuration
> architectures and _then_ know which ones we have and thus which one to
> set() as the default.
Very much so. Looking through the script there seems to be a possibility for a lot of improvements. (Maybe look into a bit of refactoring).
> I'll try to come up with a good solution to this, but no promises :-P
Mail me if you need input. I'll see if I can get around to learn a bit of ruby.
Yes, CMake offers architecture-specific build generation, and one could argue that in a per-config build philosophy, that's entirely correct and fully sufficient. It's just that it cannot generate a build environment which is able to switch 32/64 config within. Which... isn't really required, I'd say.
> Even so, VS gives you the option of other configurations
> as well, so I'm not entirely sure how those should be mapped.
That's not within v2c's responsibility, since we simply translate the configurations.
The CMake user (which possibly has other native CMake projects integrated) would then have to make sure that he offers support for the same build configuration range as described by the VS projects.
Unless we want to add a build configuration string mapper configuration file mechanism to v2c ;)
(very healthy massive overkill, I'd guess)
> Very much so. Looking through the script there seems to be a possibility
> for a lot of improvements. (Maybe look into a bit of refactoring).
Heh. Such as?
I've been doing some refactoring compared to the original script myself,
but I'm afraid I was additionally hampered by not being Ruby-skilled.
> Mail me if you need input. I'll see if I can get around to learn a bit of
> ruby.
No need to, this script is "self-contained" :-P
(read: it contains all my - borderline minimal! - Ruby knowledge, i.e. it should be relatively easy to grasp, and anything else would be so minor as to quickly be gathered via Google searches and implemented)
I'm afraid I'll have to split parsing and generation stages completely in the very near future, in order to cleanly implement the architecture configuration conditionals. Oh well, I'm sure I've only been waiting for a nicely valid reason to get this fixed to turn up anyway ;)
About the refactoring: Currently the whole process or nearly the whole process is rather imperative. The vcproj parsing could be done in a class (actually probably several), as can the rest of the process, including the generation of the cmake file.
Also, I'm not really familiar with ruby either, but it seems to me there is no requirement for self-containedness other than the design choice you made?
Ah, no, I probably shouldn't have abused the rather very specific word "self-contained" in clever(?) ways...
I simply meant that the script already contains pretty much any functionality one needs to further extend it,
thus in most cases it ""should"" be pretty easy to understand and modify.
As to classes, yes, that probably is a good idea especially with similar classes for different parsers,
but that was very far from my wishlist when starting to extend the original script :)
Oh my... what should I say?
That crucial bug is now a lot older than I would have wanted it to be. Reasons:
- script originally wasn't prepared for the change (long since done)
- I somehow naively believed that the large changes had already magically coped for this infrastructure issue. Of course not... Some 2 months ago I realized that "something" was missing...
- myself I **still** happen to actually not need this (albeit for most people crucially important!) feature
I've now added initial infrastructure for this platform selection mechanism (to feature branch feat_multi_platform).
I expect that about the same amount of work remains to additionally be done to get it to be fully useful (will continue ASAP, prio #1).
Thanks and sorry!
This crucial feature should now be working fine (well, more or less). I just checked proper operation on a large (non-multi-platform) build setup. Thus I now merged the feature branch feat_multi_platform into the standard experimental_unverified tree, and I'll let it simmer there some more.
Please report if somebody is having trouble with it, especially since I cannot (yet?) test it on my main setup. Thanks!
This feature is now deemed working. So unless someone happens to test it and state that it doesn't work, I'm now threatening to close this bug :)
Thanks for listening, have a nice time!
Closing :)