[CMake] Building multiple configurations with Xcode?

[clinton at elemtech.com]

----- Original Message -----
> 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

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.


> 
> 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)

See the case above.

> 
> >> > 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.

> 
> >> 
> >> 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?

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.  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.

Clint