View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0001962CMakeCMakepublic2005-06-22 04:232005-07-14 20:56
ReporterEric Wing 
Assigned ToBill Hoffman 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0001962: Xcode generated project should respect MACOSX_BUNDLE option
DescriptionThe Xcode generated project currently creates a Unix style application target, regardless if the MACOSX_BUNDLE option is specified in the CMakeLists.txt. A proper .app bundle fails to be created.

It seems that if the MACOSX_BUNDLE option is specified, the generator should specify a more native type of target (Cocoa/Carbon?) so a bundle will be created.

This is a problem because flat Unix style executables are a problem for programs that create Aqua windows (not X11). There seem to be issues where a program that is a flat executable will prevent windows that are spawned from getting mouse/keyboard focus.
TagsNo tags attached.
Attached Files

 Relationships

  Notes
(0002584)
Sean McBride (reporter)
2005-07-04 13:42

There is a through discussion here:
<http://www.cocoabuilder.com/archive/message/cocoa/2005/1/20/126215> [^]

about the fact that, as ewing says, "a flat executable will prevent windows that are spawned from getting mouse/keyboard focus."
(0002651)
Bill Hoffman (manager)
2005-07-14 08:40

I have fixed this for CVS, please try and verify that it works. If it works for you I will move it into 2.2.1.
(0002671)

2005-07-14 18:39

First, the current CVS seems to have some problems (2005/07/14). The process complains about missing jni.h though it does exist on the system under the JavaVM.framework I think. There are also missing files in the doc directory which causes an error on 'make install'.

That out of the way, there seem to be a number of problems when I try using this patch. I think most of them stem from the fact that Xcode 2.1 breaks your assumptions you made for Xcode 1.5/2.0. I no longer can test under older versions of Xcode as we move forward to bigger issues looming (Universal Binaries).

But the big problem seems to be that Xcode now places built products in a different location than before. Before, everything got dumped into the build folder under the Xcode project. Now Xcode has introduced "Build Configurations". This similar to how Visual Studio does a Debug
and Release versions. You can create custom build configurations or use the default ones "Debug", "Release", "Default".(If you import an older Xcode project instead of creating a new one, the configuration names are "Development" and "Deployment" instead of "Debug" and "Release".)

The impact of this is that built products are now isolated into their own subdirectory based upon the configuration name, sort of like how Visual Studio separates Debug and Release files into separate directories. This way you can change build styles without cleaning/overwriting your other built products in case you switch often. So for example, my program might be placed in "build/Development" instead of just "build" if I use a configuration called "Development".

So when I tested on a small project I have that builds a dynamic library, and then builds a program (.app bundle) that uses it, there are several points of breakage.

First, the library gets built under the build configuration subdirectory. Then when the program tries to link to it, it cannot find the library. I noticed that you hard code the -l flag and header path into the target. As we had discussed in a previous email, I think a better way to handle this might be to enable the check box on the library that this target depends on. We discussed that this probably won't work for static libraries, but should (hopefully) work for dynamic libraries. The long term advantage of doing this (I believe) is that Xcode carries more responsibility for finding things. So if Apple changes stuff again, you might be immune. Apple also hides a lot of complexity in Xcode. I've already discovered there are certain bugs with their version of gcc when invoking combinations of flags or specifying flag order that will cause your compile to fail or not build correctly. Xcode tries to hide all this so you don't get tripped up on these. (This is also probably why Apple didn't spot these bugs since they all use Xcode internally.) The other reason to support the checkbox approach is that Xcode provides you simple visual feedback about how your project is constructed without having to search through hundreds of command options. Mac users tend to like simple, informative displays.

So after this, I modified the search path to look in the correct directory for the library. But the next problem is that the bundle was not created correctly. Instead of MyProg.app/Contents/MacOS/MyProg, the bundle looked like MyProg.app/Contents/MacOS/Deployment/MyProg.

It looks like you're invoking a shell script on the Unix Executable target to create the bundle. Once again my advice would be to consider invoking a Cocoa Application target instead if the MACOSX_BUNDLE option appears instead of the Unix Executable target. As before, this would put more of the burden on Xcode rather than you and is less likely to break in future Xcode changes. And Mac users get nice visual feedback (a different icon and target options) about what what is being built.

With all the negative stuff I just had to describe, I just wanted to say again, thanks for working on this, and that your work on this really is appreciated.












(0002672)
Eric Wing (reporter)
2005-07-14 18:40

First, the current CVS seems to have some problems (2005/07/14). The process complains about missing jni.h though it does exist on the system under the JavaVM.framework I think. There are also missing files in the doc directory which causes an error on 'make install'.

That out of the way, there seem to be a number of problems when I try using this patch. I think most of them stem from the fact that Xcode 2.1 breaks your assumptions you made for Xcode 1.5/2.0. I no longer can test under older versions of Xcode as we move forward to bigger issues looming (Universal Binaries).

But the big problem seems to be that Xcode now places built products in a different location than before. Before, everything got dumped into the build folder under the Xcode project. Now Xcode has introduced "Build Configurations". This similar to how Visual Studio does a Debug
and Release versions. You can create custom build configurations or use the default ones "Debug", "Release", "Default".(If you import an older Xcode project instead of creating a new one, the configuration names are "Development" and "Deployment" instead of "Debug" and "Release".)

The impact of this is that built products are now isolated into their own subdirectory based upon the configuration name, sort of like how Visual Studio separates Debug and Release files into separate directories. This way you can change build styles without cleaning/overwriting your other built products in case you switch often. So for example, my program might be placed in "build/Development" instead of just "build" if I use a configuration called "Development".

So when I tested on a small project I have that builds a dynamic library, and then builds a program (.app bundle) that uses it, there are several points of breakage.

First, the library gets built under the build configuration subdirectory. Then when the program tries to link to it, it cannot find the library. I noticed that you hard code the -l flag and header path into the target. As we had discussed in a previous email, I think a better way to handle this might be to enable the check box on the library that this target depends on. We discussed that this probably won't work for static libraries, but should (hopefully) work for dynamic libraries. The long term advantage of doing this (I believe) is that Xcode carries more responsibility for finding things. So if Apple changes stuff again, you might be immune. Apple also hides a lot of complexity in Xcode. I've already discovered there are certain bugs with their version of gcc when invoking combinations of flags or specifying flag order that will cause your compile to fail or not build correctly. Xcode tries to hide all this so you don't get tripped up on these. (This is also probably why Apple didn't spot these bugs since they all use Xcode internally.) The other reason to support the checkbox approach is that Xcode provides you simple visual feedback about how your project is constructed without having to search through hundreds of command options. Mac users tend to like simple, informative displays.

So after this, I modified the search path to look in the correct directory for the library. But the next problem is that the bundle was not created correctly. Instead of MyProg.app/Contents/MacOS/MyProg, the bundle looked like MyProg.app/Contents/MacOS/Deployment/MyProg.

It looks like you're invoking a shell script on the Unix Executable target to create the bundle. Once again my advice would be to consider invoking a Cocoa Application target instead if the MACOSX_BUNDLE option appears instead of the Unix Executable target. As before, this would put more of the burden on Xcode rather than you and is less likely to break in future Xcode changes. And Mac users get nice visual feedback (a different icon and target options) about what what is being built.

With all the negative stuff I just had to describe, I just wanted to say again, thanks for working on this, and that your work on this really is appreciated.

(0002673)
Bill Hoffman (manager)
2005-07-14 20:56

Well, at some point I will create an XCode 2.x generator. I don't think I can support XCode 2.x from a 1.5 generator, and if the auto-conversion does not work to bad, it does not work for VS 6 to VS 7 either. I will look into the library stuff, but it is somewhat involved. Right now the XCode generator shares a bunch of code with the regular unix generator, and I consider that a nice to have, it is also awkward to treat shared and static libraries differently. The problem I have now is that if I install Xcode 2.1 on our box, I will loose XCode 1.5 for testing. There are folks out there that can not or do not want to upgrade.


 Issue History
Date Modified Username Field Change


Copyright © 2000 - 2018 MantisBT Team