[CMake] Building multiple configurations with Xcode?

[Clinton Stimpson]

On Friday, May 03, 2013 05:48:20 PM Stephen Kelly wrote:
> 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 ?

Actually
Release/foo.framework/foo
Debug/foo.framework/foo

are valid frameworks.  You can use -F/path/to/framework/Debug for a debug 
build and -F/path/to/framework/Release for a release build.

That's basically identical to have a release-only Qt installed in one place, 
and a debug-only Qt installed in another place.  Or even a single configuration 
build tree in one place, and another build tree in another place.

So, CMake doesn't have issues in the build tree.  It only a problem in the 
install tree when trying to put multiple configurations in the same tree.


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

For closed source, they could gather some meaningful information with a debug 
framework.  Having a
foo.framework/Versions/A/foo
foo.framework/Versions/A/foo_debug
would be a quick way for them to debug by setting DYLD_IMAGE_SUFFIX=_debug.

That's certainly quicker than recompiling their app against a debug framework 
in a different location.

But, if I chose to give them this:
Release/foo.framework/Versions/A/foo
Debug/foo.framework/Versions/A/foo
and their debug build was already linked with the debug foo framework, then 
debugging can already be done without setting any environment variable to tell 
the dynamic loader to use a different library.

There are a few options here.

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

qmake links your apps against the framework (which under the covers means it 
is linked with the release Qt libraries), even for a debug build of your 
application.  CMake and qmake behave the same here when developing a Qt based 
app.

The DYLD_IMAGE_SUFFIX approach that works with Qt is to modify the Qt 
frameworks and rename the _debug files to _qtdebug.  Then I set 
DYLD_IMAGE_SUFFIX=_qtdebug when running the application to debug the Qt 
libraries without debugging all system libraries (some of which are broken 
depending on the OS X version).

-- 
Clinton Stimpson
Elemental Technologies, Inc
Computational Simulation Software, LLC
www.csimsoft.com