[CMake] Building multiple configurations with Xcode?

[Stephen Kelly]

clinton at elemtech.com wrote:
>> Or
>> 
>>  Release/foo.framework/foo
>>  Debug/foo.framework/foo-d
> 
> Ok, but the framework version of the linker flags -L,-l are used like
> this: -F/path/to/framework -framework foo
> which result in the linker would look for this file
> /path/to/framework/foo.framework/foo
> 
> So, Debug/foo.framework/foo-d is not a valid framework.

CMake seems to already be putting the framework in a Debug/Release folder. 
Does that mean that they are not valid frameworks in the build dir? Does 
that mean they can't be used from the build dir at all? 

What if you use -F/path/to/framework/Debug ?

>> 
>> >> > 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?
> 
> With the -F/-framework link flags, the linker looks for
> "foo.framework/foo" The DYLD_* variables are used by the dynamic loader at
> runtime and do not affect the linker.

I see. 

I wonder if this leaves us in a solvable situation.

>> ... 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?
> 
> Yes.  Its a separate step to handle multiple configurations, like you did
> earlier. cmake --build . --target install --config Debug
> cmake --build . --target install --config Release
> 
> And yes, with frameworks, there is the issue of overwriting files.
> I don't really care about this problem, yet.  Only on windows is a debug
> library required for regular development because of the configuration
> specific C/C++ runtime libraries.
> 
> If I made a framework for other people to use, and if for some reason they
> wanted to debug my framework, they could simply compile a debug only
> version and link with that.  So I don't see a big need for both a release
> and debug framework.

Closed source is not common/relevant?

> In the past, when I've had to debug the Qt libraries
> on Mac, I've either made a debug only build, or modified the frameworks. 
> The modification was because Qt uses the same "_debug" suffix as the whole
> system, and I don't want the debug version of all of the system libraries
> because it is way too slow.  So anyway, for me, this is a very low
> priority problem compared to other cmake issues.

Right.

The reporter at https://bugreports.qt-project.org/browse/QTBUG-30938 raises 
a reason that DYLD_IMAGE_SUFFIX doesn't work for him anyway. I wonder what 
qmake does here.

Thanks,

Steve.