[CMake] Building multiple configurations with Xcode?

[Stephen Kelly]

clinton at elemtech.com wrote:

> 
> 
> ----- Original Message -----
>> clinton at elemtech.com wrote:
>> 
>> > 
>> > 
>> > ----- Original Message -----
>> >> Stephen Kelly wrote:
>> >> 
>> >> > Is it possible to build multi-config frameworks with cmake at all?
>> >> 
>> >> I also notice that the Framework unit test uses
>> >> 
>> >>  set_target_properties(foo PROPERTIES
>> >>    FRAMEWORK TRUE
>> >>    DEBUG_POSTFIX -d
>> >>  )
>> >> 
>> >> but the debug file is called 'foo', not 'foo-d'. If I use
>> >> 
>> >>  cmake --build . --target install --config Debug
>> >>  cmake --build . --target install --config Release
>> >> 
>> >> the debug and release versions overwrite each other.
>> >> 
>> >> Does this mean it has always been broken? Has no one ever tried to
>> >> create a framework using cmake?
>> > 
>> > In the build tree, I would expect "foo" not "foo-d" for the debug
>> > framework.
>> > And in the build tree, it is possible to differentiate the release from
>> > debug simply by having two "foo.framework/foo".  One will be in the
>> > Release folder and one in the Debug folder, and a Debug build will use
>> > the one from the Debug folder, while the release build will use the one
>> > from the Release folder.
>> 
>> That indeed appears to be what happens.
> 
> But, I personally don't see a problem with there being a
> "foo.framework/foo" and a "foo-d.framework/foo-d". At install time, they
> would not overwrite each other and the export file would need to list both
> of them.

Or 

 Release/foo.framework/foo
 Debug/foo.framework/foo-d

for a presumably smaller change. I don't know about export(), but 
install(EXPORT) is already fine. It installs multiple targets-<config>.cmake 
files, where each one would reference the correct 
IMPORTED_LOCATION_<CONFIG>. I just assumed that was already implemented.

You might be able to tell me if there's some other location/file in a 
framework that would break though? (update: I think I understood below)

>> > For the install tree, I don't see how it is known which configurations
>> > will be installed.
>> 
>> I'm not familiar with xcode, so I assumed that if you install it would
>> install all configurations, or you would specify which you want to
>> install.
> 
> Xcode works in one configuration at a time.
> The install target is the same way, by installing only one configuration
> at a time.

Ok, so you specify the configuration you want *this time? Then the 
configuration is known, right? We don't need to know all configurations that 
will be installed because of the multiple targets files.

>> When I use the command line I use
>> 
>>  cmake --build . --target install --config Debug
>> 
>> so it is specified.
> 
> That one configuration was specified, yes.  But it isn't known if the
> Release one will also be installed. 

> If it is known they are both being
> installed, and one wanted them to both go into the same framework, then
> the debug one can be renamed to and the burden put on the user to specify
> DYLD_IMAGE_SUFFIX to run their application with the debug library. 

"renamed to foo_debug" ? I don't know for certain, but it seems that that is 
the common way of creating these things, right?

> If only
> the Debug configuration is installed, and it was still renamed, you'd have
> a broken framework.

Ah, I think I understand now.

If I install both debug and release, then I get

 foo.framework/foo
 foo.framework/foo_debug

but if I install only the debug version, then I get only

 foo.framework/foo_debug

And, you're saying that the framework system is not smart enough to work 
with that because the non-_debug version is missing? It doesn't just append 
the DYLD_IMAGE_SUFFIX on the name of the framework, and after locating the 
framework use that as the name of the file?

>> 
>> So, I don't know what you mean here. Can you be more specific, keeping in
>> mind I don't know xcode?
> 
> The behavior is basically the same as visual studio, if you know that,

I'm afraid I never used it extensively or for c++.

> with the addition of this framework concept. While the whole build system
> supports multiple configurations, the user is only in one configuration at
> a given time.

... and the user can only install/create their own frameworks as one 
configuration at a time? The user can't easily create/install multi-config 
frameworks?

>> 
>> I left a comment on the original Qt bug above that he should look into
>> using DYLD_IMAGE_SUFFIX. Is that right?
> 
> That is the correct response in the context of Qt.

Thanks!

Steve.