<div class="gmail_quote">On Sun, Oct 9, 2011 at 7:49 AM, Michael Hertling <span dir="ltr"><<a href="mailto:mhertling@online.de">mhertling@online.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5">On 10/09/2011 02:09 AM, michael lowell roberts wrote:<br>
> On Sat, Oct 8, 2011 at 6:40 AM, Michael Hertling <<a href="mailto:mhertling@online.de">mhertling@online.de</a>>wrote:<br>
><br>
>> On 10/08/2011 05:33 AM, michael lowell roberts wrote:<br>
>>> Hi all,<br>
>>><br>
>>> I'm attempting to use the ExternalProject module to compile and link<br>
>> against<br>
>>> a library and I've run into a problem that I'm not certain how to<br>
>> address.<br>
>>> I'm using CMake 2.8.6 and Visual Studio 10 Express.<br>
>>><br>
>>> The external project, in my case, is a CMake-compiled project and CMake<br>
>>> predictably builds a matching configuration in the external project.<br>
>>><br>
>>> The target_link_libraries() command, however, only allows for two<br>
>>> configurations, at most, mapped to labels "debug" and "optimized."<br>
>>><br>
>>> This allows for only two of the four default build configurations to<br>
>>> complete successfully.<br>
>>><br>
>>> For example, in my build scripts, I have told target_link_libraries() to<br>
>> map<br>
>>> "debug" configurations to the Debug version of library and optimized<br>
>>> configurations map to the "RelWithDebInfo" build of the library.<br>
>> Therefore,<br>
>>> if I build the "Release" configuration, I get linker errors because the<br>
>>> external project was also built with the "Release" configuration but I<br>
>> need<br>
>>> to link against "RelWithDebInfo."<br>
>>><br>
>>> It seems to be that no matter how the target_link_library() mappings are<br>
>> set<br>
>>> up, only half of the default configurations will build properly because<br>
>> of<br>
>>> the dualism that target_link_libraries() uses.<br>
>>><br>
>>> How do I get all four default build configurations working?<br>
>>><br>
>>> Regards,<br>
>>> Mike<br>
>><br>
>> Could you boil down this issue to a minimal but self-contained<br>
>> exemplary project and post it here for further investigation?<br>
>><br>
><br>
> Certainly.<br>
><br>
> I've attached a sample project that downloads and compiles the trio library,<br>
> which can be found at the following site:<br>
><br>
> <a href="http://daniel.haxx.se/projects/trio/" target="_blank">http://daniel.haxx.se/projects/trio/</a><br>
><br>
> It then attempts to link the library into a trivial executable that simply<br>
> prints a message to the screen.<br>
><br>
> The build exhibits the problem I mentioned. Debug builds complete<br>
> successfully. Release builds do not.<br>
<br>
</div></div>Okay, I was able to reproduce the issue. In fact, it is caused by your<br>
manual mapping of configurations between your project and the external<br>
project via TARGET_LINK_LIBRARIES()' debug/optimized keywords. However,<br>
that's inappropriate anyways; you should use an imported library along<br>
with its IMPORTED_LOCATION_<CONFIG> target properties instead. Look at<br>
the attached trio.cmake file or the related diff, respectively. With<br>
the new trio.cmake, I was able to build all configurations of the<br>
exemplary project flawlessly, but please consider this just as a<br>
hotfix, not a rock-solid solution.<br></blockquote><div><br></div><div>That makes sense; thanks.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
> Additionally, the IDE appears incapable of determining when the build is<br>
> up-to-date. Try to debug the executable to reproduce this problem. I'm<br>
> inclined to believe that this is due to something I've done wrong and any<br>
> help with this problem would also be appreciated.<br>
<br>
</div>I can't confirm this. When the test.c file ist touched, Visual Studio<br>
recompiles it and relinkes the final executable as it should, and if<br>
nothing has changed, nothing does happen. Could you provide further<br>
information when the IDE does not behave as expected?<br></blockquote><div><br></div><div>I'm still experiencing this problem. When I start the debugger, Visual Studio presents me with a dialog asking if I want to rebuild trio and ZERO_CHECK.</div>
<div><br></div><div>I'm not sure it matters anymore, however, in light of the remainder of what you've said.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
> Lastly, I'm certain that there are other problems I have not identified yet.<br>
> If you could point out anything else that is obviously problematic, I would<br>
> be grateful. Perhaps I am over-complicating the code, for example.<br>
<br>
</div>Hhm, yes, this might be the case... ;) Besides, there was a minor flaw<br>
with include_directories(), see the diff, and constructions like<br>
<br>
get_filename_component(TRIO_PREFIX "${TRIO_LIBRARY}" PATH)<br>
<br>
doesn't seem to work well if TRIO_LIBRARY is something like<br>
<br>
debug;.../lib/Debug/trio.lib;optimized;.../lib/RelWithDebInfo/trio.lib<br></blockquote><div><br></div><div>I'm having one of those "I wonder why it worked at all?" moments. :)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
AFAICS, the basic problem is that you need the trio library already<br>
installed when your actual project is configured, and this can't be<br>
done by a simple external project because the latter is completely<br>
processed at build time, i.e. when your project's configuration is<br>
already finished. For that reason, you need lines like<br>
<br>
if(WIN32)<br>
set(TRIO_LIBRARY_NAME trio.lib)<br>
else()<br>
set(TRIO_LIBRARY_NAME libtrio.a)<br>
endif()<br>
<br>
which is usually performed by CMake's FIND_LIBRARY() automatically.<br></blockquote><div><br></div><div>OIC. I appreciate you reminding me of this. It makes a lot of things clearer.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
IMO, possible solutions are:<br>
<br>
- Integrate the external project's code base in your project's one,<br>
set it up appropriately and process it with an ADD_SUBDIRECTORY().<br>
However, in this way, you'll miss the external project's upstream.<br>
- Apply the so-called super-build approach, i.e. provide a top-level<br>
CMakeLists.txt that pulls in the foreign project *and* your actual<br>
project as external projects with your project being the last one.<br>
In this manner, the foreign project is already build and possibly<br>
installed when your project is configured, so you can use CMake's<br>
FIND_*() commands to locate the foreign project's files. However,<br>
you must explicitly forward each variable that should be used in<br>
your project from the top-level CMakeLists.txt to your project's<br>
ExternalProject_Add() invocation, and there might also be issues<br>
w.r.t. the projects' common installation, see [1].<br>
<br>
'hope that helps.<br></blockquote><div><br></div><div>It does. I'm going to elect for the add_subdirectory() approach. </div><div><br></div><div>The super-build option doesn't seem especially useful for a project that I'm using to actively develop source code. The IDE only shows custom build rules for an external project, not the source files I would want convenient access to. It seems that the super-build option is more appropriate for collecting related projects into something like an automated build process.</div>
<div><br></div><div>Thanks again for your help and wisdom.</div><div><br></div><div>Regards,</div><div>Mike</div></div>