|
Notes |
|
|
(0012267)
|
|
Nils Gladitz
|
|
2008-06-06 04:09
|
|
Apparently there is a command line tool included with intel's windows compiler that could do the conversion.
In version 10 of the compiler that tool is called ICProjConvert100.exe.
Maybe this could be used from within cmake to create an intel generator which does exactly what the visual studio generator does but additionally calls ICProjConvert*.exe (?) |
|
|
|
(0022353)
|
|
mhulboj
|
2010-09-26 10:31
(edited on: 2010-09-26 10:53) |
|
I have worked a bit on the problem of Intel Projects in Visual Studio. I think that the best solution would be to allow per-project enabling of the .icproj file generation (exactly as with the VS Intel macros or ICProjConvert tool).
I have made a patch with the draft implementation of my idea (against 2.8.3-rc1). I don't know the CMake internals, and maybe some things could be simplified or should be done in a different way.
The solution is rather simple, we need to:
- generate .icproj when needed
- use the .icproj GUID instead of .vcproj when referring to the project in the SLN file (when it comes to folders, dependencies).
- both .vcproj and .icproj GUIDs are being put in the ProjectConfigurationPlatforms (Intel tool does that as well)
Most of the hassle comes from checking whether the project is tagged as Intel and providing additional GUIDs.
Usage:
add_executable(hello hello.cpp)
set_property(TARGET hello PROPERTY VS_INTEL_PROJECT)
I have tested this approach on several projects and it seems to be working without problems.
See the patch comment for more details.
|
|
|
|
(0022355)
|
|
Nils Gladitz
|
|
2010-09-26 11:19
|
|
Personally I would prefer if intel project generation would not be hardcoded into CMakeLists.
I would want to be able to build my projects both with visual studio (and its own compiler) and intel's compiler without having to modify my project descriptions.
Also I wouldn't want to build existing cmake projects that aren't "intel aware" without modification.
Maybe this could be done via separate cmake generators parallel to the existing Visual Studio specific generators instead? Or maybe some additional "intel mode" flag that would be interpreted by the current Visual Studio generators? |
|
|
|
(0022356)
|
|
mhulboj
|
2010-09-26 11:24
(edited on: 2010-09-26 11:29) |
|
For me, it's more a project property. I can have a solution that has both Intel and non-Intel projects. Having a separate generator would not allow that.
And I can always put the necessary logic (one variable + an IF) in the CMakeLists.txt - to decide about the project type.
Most likely there could be a global CMake property that when passed to CMake VS generator would enable Intel project for all suitable targets?
|
|
|
|
(0022357)
|
|
Nils Gladitz
|
|
2010-09-26 11:44
|
|
Then how about a flag parallel to the generator that can set intel as the default compiler and then the option to override this default per target?
e.g.
I have a CMakeLists.txt with targets target1 and target2
- cmake -G "Visual Studio 8 2005" [...]
=> both target1 and target2 are regular vc projects
- cmake -G "Visual Studio 8 2005" -DCMAKE_VS_PROJECT_TYPE=Intel [...]
=> both target1 and target2 are intel projects
- cmake -G "Visual Studio 8 2005" [...]
modified CMakeLists.txt that does:
set_property(TARGET target2 PROPERTY CMAKE_VS_PROJECT_TYPE Intel)
=> target1 gets regular vc project, target2 gets an intel project |
|
|
|
(0022401)
|
|
mhulboj
|
|
2010-10-03 17:39
|
|
That's exactly what I had in mind in my previous comment.
However, before looking into that, I'd appreciate some comments from the CMake side as to the code.
It would also be nice if someone else tried to use this patch and tell whether he/she has any problems. |
|
|
|
(0022403)
|
|
Brad King
|
|
2010-10-04 14:09
|
|
I'm a CMake dev. I like the project-wide and per-target switch flexibility. It will be easier to test the patch with the project-wide switch available too.
In Source/cmTarget.cxx find the "cmTarget::SetMakefile" method. Add this call:
this->SetPropertyDefault("VS_PROJECT_TYPE", 0);
(next to other calls that look like this). Then check the VS_PROJECT_TYPE property in the generator for the value "Intel" or "MSVC". Reject other values. The SetPropertyDefault method will automatically use the value of the variable "CMAKE_VS_PROJECT_TYPE" as it is at the time the target is created.
This approach provides the project-wide switch by default but allows each project to provide its own per-target options. |
|
|
|
(0022407)
|
|
Nils Gladitz
|
|
2010-10-05 04:27
|
|
I applied the patch and the proposed changes.
My TargetIsIntelProject implementation now looks like this:
bool cmGlobalVisualStudio71Generator::TargetIsIntelProject(cmTarget& t)
{
std::string vs_project_type = "MSVC";
const char* tmp = t.GetProperty("VS_PROJECT_TYPE");
if(tmp) vs_project_type = tmp;
if(vs_project_type == "MSVC") return false;
else if(vs_project_type == "Intel")
{
return !this->TargetIsFortranOnly(t);
}
else
{
std::stringstream message;
message << "Target: " << t.GetName() <<
" has unknown VS_PROJECT_TYPE '" <<
vs_project_type << "'";
cmSystemTools::Error(message.str().c_str());
return false;
}
}
- cmake -G "Visual Studio 8 2005" -DCMAKE_VS_PROJECT_TYPE=Foobar
Fails my Hello World target as expected but the "Check for working ... compiler ..." checks still seem to work. Don't these use the same Generator?
- cmake -G "Visual Studio 8 2005" -DCMAKE_VS_PROJECT_TYPE=MSVC
Generates only Visual Studio projects as expected
- cmake -G "Visual Studio 8 2005" -DCMAKE_VS_PROJECT_TYPE=Intel
Generates additional Intel projects (for my Hello World target, ALL_BUILD and ZERO_CHECK) and builds ok.
I then tried adding a new source file to the project and modified CMakeLists.txt accordingly.
After reloading the solution in Visual Studio and issuing the build command cmake regenerates the solution as expected and causes visual studio to open several dialog boxes asking to reload the solution and stopping the build
(I think so far that part is identical to a regular Visual Studio build).
After confirming all those dialogs Visual Studio displays "Running macro ..." in the status line and just hangs.
I couldn't stop the macro invocation except by killing visual studio from the task manager.
I don't know what might cause this or how to debug it but closing Visual Studio and running cmake manually does seem to work around it.
I was unable to reproduce the problem with -DCMAKE_VS_PROJECT_TYPE=MSVC. |
|
|
|
(0022408)
|
|
mhulboj
|
|
2010-10-05 05:05
|
|
I can comment on the problem of "Running macro..." - with normal CMake, without the patch.
I get it from time to time when working with CMake projects under Visual Studio that have been converted to Intel Projects:
- Generate VS solution
- Convert it to Intel (either using the command line tool or the macro)
- Add changes to CMakeLists.txt
- Try regenerating the solution - get lots of popups and sometimes VS hangs. If I choose not to reload individual .vcproj, and only the whole solution this does not happen.
- Solution reloaded - has to convert to Intel again
Don't have a clue what causes the problem. |
|
|
|
(0022410)
|
|
mhulboj
|
|
2010-10-05 09:30
|
|
I've applied your modifications and it seems to be working fine for me. I've tried it both on my project and on the standard CMake. Both the global and local options seem to be working fine:
Using -DCMAKE_VS_PROJECT_TYPE sets the default for all the projects that do not have explicit local value set:
set_property(TARGET hello PROPERTY VS_PROJECT_TYPE=Intel)
set_property(TARGET hello PROPERTY VS_PROJECT_TYPE=MSVC)
I don't know what to do about the macro hanging stuff. It seems to be related to the Intel Projects, but I was experiencing that even before using this patch. |
|
|
|
(0022415)
|
|
Brad King
|
|
2010-10-06 08:37
|
|
All CMake's tests pass with the patch series through 0002 when CMAKE_VS_PROJECT_TYPE is not set.
I tested the patch on CMake's "COnly" test with -DCMAKE_VS_PROJECT_TYPE:STRING=Intel. The libraries and executables build but the ALL_BUILD target fails with "Error: Canceled". In the IDE I switched the project back to VS-only. Then I removed the ALL_BUILD.icproj file and asked the IDE to make it an Intel project again. It rejected the request with this error:
Projects failed to update:
ALL_BUILD -- Unsupported Project Type. Intel C++ does not support the utility configuration type setting found in the "Debug|Win32" configuration.
Please update the patch to ignore VS_PROJECT_TYPE for targets that return anything other than EXECUTABLE, STATIC_LIBRARY, SHARED_LIBRARY, or MODULE_LIBRARY from cmTarget::GetType(). |
|
|
|
(0022417)
|
|
Nils Gladitz
|
|
2010-10-06 10:52
|
|
from the first patch in Source/cmTarget.cxx there still is:
cm->DefineProperty("VS_INTEL_PROJECT" [...]
should probably update the property name and description appropriately |
|
|
|
(0022469)
|
|
mhulboj
|
|
2010-10-10 17:41
|
|
|
I've addressed the last two comments in 0003 and 0004 patches. It doesn't generate .icproj files for special targets and the property description has been updated. |
|
|
|
(0023567)
|
|
Francesco Baralli
|
|
2010-11-29 08:40
|
|
I've noticed a problem with the current VisualStudio generator followed by the ICProjConverter: since CMake starts assuming MSVC as compiler Intel specific optimization flags are discarded.
Is this fixed in your implementation?
Thanks |
|
|
|
(0023635)
|
|
mhulboj
|
|
2010-12-01 08:15
|
|
No, and this might be problematic in some cases. There are several levels at which options can be declared and they don't mix-up to well.
- There are standard Visual-Studio like options that are being stored in the .vcproj.
- There are additional Intel Compiler options that are being stored in the .icproj (I don't touch them currently - so VS assumes defaults)
- You can specify additional compiler flags in CMake - currently they will be mixed with the others and the `stronger' will win (warning level, etc.).
It's not ideal and for now I don't have idea how to solve this in a clean way. |
|
|
|
(0028302)
|
|
thesaint
|
2012-01-15 13:17
(edited on: 2012-01-15 13:22) |
|
Hi,
I've added a little C# script "CMakeVSPostfix.cs" (see above) which takes two parameters:
1) the build directory where CMake puts all the projects
2) the new toolset that shall be applied to all C++ projects in that directory (existing toolsets are updated).
This script can now be run with your Intel Compiler toolset, for example "Intel C++ Compiler XE 12.1" and viola, VS now uses the intel compiler for building your projects. Additionally, it touches the solution file to prevent reloading of all project. Instead VS will just reload the entire solution. You have to manually invoke cmake and the script using a batch file for example, everytime you change the CMake configuration, e.g. one of these "CMakeLists.txt" files..
I recommend disabling the CMake macro, otherwise this thing will probably not work!
The script is intended for Visual Studio 2010 and may not work for anything else!
Hope this helps.
regards
chris
|
|
|
|
(0028303)
|
|
thesaint
|
2012-01-15 14:27
(edited on: 2012-01-15 14:35) |
|
I found a better way I guess. Just download the latest CMake and compile from source. The thing you have to do is goto to the file "cmVisualStudio10TargetGenerator.cxx" and method "void cmVisualStudio10TargetGenerator::WriteProjectConfigurationValues()".
Now just patch the following code at the end of the method:
"
if(const char* toolset = gg->GetPlatformToolset())
{
std::string pts = "<PlatformToolset>";
"
with this snippet:
"
if(this->Target->GetProperty("PLATFORM_TOOLSET"))
{
this->WriteString(((std::string)"<PlatformToolset>" + this->Target->GetProperty("PLATFORM_TOOLSET") + "</PlatformToolset>").c_str(), 2);
}
else if(const char* toolset = gg->GetPlatformToolset())
{
std::string pts = "<PlatformToolset>";
"
Now you can simply set the platform toolset from within a CMakeLists.txt file by using:
"
set_target_properties(${YOUR TARGET} PROPERTIES PLATFORM_TOOLSET "Intel C++ Compiler XE 12.1")
"
I found this to be pretty slick, since now also the CMake macro can be used and you don't have to edit anything manually... Additionally, you can set custom toolsets for every single project.
Of course if you really need the project itself to be intel, then you're out of luck with this simple approach. But since ICProjConvert does not work for me (because it just doesn't do anything), I have no other choice. And setting the toolset does the job, doesn't it? After all, you can pass all intel compiler specific flags from within CMakeLists.txt, so there shall be only rare cases where you really need an intel project?!
regards
Christoph Husse
|
|
|
|
(0041423)
|
|
Kitware Robot
|
|
2016-06-10 14:27
|
|
Resolving issue as `moved`.
This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page. |
|
0001-ADDED-Initial-support-for-VS-Intel-Projects.patch (12,709) 2010-09-26 10:31
CMakeVSPostfix.cs (5,966) 2012-01-15 13:13