|
Notes |
|
|
(0003492)
|
|
Bill Hoffman
|
|
2006-01-02 12:56
|
|
|
Can you describe how an Xcode project should be layed out in this bug report? |
|
|
|
(0003514)
|
|
Bill Hoffman
|
|
2006-01-05 09:09
|
|
OK, so if I still want a folder per target. Otherwise large projects like VTK or ITK end up with single sources folder that is just out of control, with hundreds of files. This is what Xcode does by default. So, I can remove the Headers on the Mac, and have:
TargetName/Sources
and remove TargetName/Headers
Does that sound good? I tried to create multiple targets from the GUI in Xcode but it does not create source files except when you create the initial project. So Xcode really gives no direction on how it would be done. How do you typically see projects with 20+ libraries breaking things up? Or even 5 or so libraries. |
|
|
|
(0003518)
|
|
|
|
2006-01-05 15:47
|
|
Yeah, in Xcode, nothing is really enforced, and things are fairly free form. But there seem to be conventions people are following, partly because of examples and how the templates are setup, partly due to Unix directory structures, and partly due to pragmatic issues about how Xcode works. (One issue about having unnecessary nested groups is that horizontal screen real-estate is at a minimum in the Groups and Files Panel so arbitrarily adding new subgroups like Headers and Source costs a lot of useless space).
So in Xcode, headers are listed; don't remove them. That would be worse.
Currently, you seem to actively seek out files within Targets and split them into:
TargetName/Headers
TargetName/Sources
Instead, you should drop the Headers and Sources subgroups so they just go in:
TargetName
I think order should reflect how they are listed in the CMakeLists.txt and don't sort them or anything.
Now it is okay to have multiple Targets and separate the files based on Target.
TargetName1
File1.h
File1.c
File2.h
File2.c
TargetName2
File3.h
File3.c
File4.h
File4.c
But I think this is a bad idea, particularly for large projects. First, this is redundant because Xcode does this grouping for you if you select the actual Target in the Groups and Files panel. (All the dependent files appear in the top-right "Detail" pane.) And if you expand the target triangle, there is a subgroup called "Compile Sources" which has all the implementation files listed. So what you are doing here may not be as useful as it could be.
Instead, it is also reasonable in Xcode to separate files based on the directory structure of your project. Each group would represent a directory. Obviously, you can get deeply nested groups in Xcode because of this, but since the project is structured this way, it conceptually matches what's really happening so it's not a bad thing. It makes it easy to find the file in the filesystem when you have to do so. I think Xcode users generally understand Unix directory structures enough so that this might actually be the preferred layout.
So for example in OpenSceneGraph, the files are laid out something like:
include/ (these are the Public API headers)
osg/ (For the osg library target)
PositionAttitudeTransform
ref_ptr
osgUtil/ (For the osgUtil library target)
SceneView
src/ (implementation files)
osg/ (for the osg library target)
dxtctool.h (note the private/internal header)
PositionAttitudeTransform.cpp
osgUtil (for the osgUtil library)
SceneView.cpp
TriStrip_tri_stripper.h
osgPlugins/ (not a target itself, but a directory containing loadable module targets)
freetype/ (for the osgDB_freetype.so target)
FreeTypeLibrary.h
FreeTypeLibrary.cpp
jpeg/ (for the osgDB_jpeg.so target)
ReaderWriterJPEG.cpp
applications/ (directory containing app targets)
osgviewer/ (for the osgviewer application target)
osgviewer.cpp
examples/ (directory containing simple example app targets)
osgbillboard/ (for the osgbillboard app target)
osgbillboard.cpp
osgplanets/ (for the osgplanet app target)
osgplanets.cpp
(I would actually encourage you to download the OSG source and check out our existing Xcode project. It would be nice if we could make the CMake generated one resemble it as much as possible.)
So things to note in this project:
- We have multiple targets, but we don't actually sort by target, but follow the directory layout structure. Most large projects seem to layout their directory structures in a sensible way so following them makes sense.
- The directory structure decided to isolate public header files in a directory called "include" (very GNU-ish). They are further subgrouped/separated by each library. Our Xcode project reflects this and has the same nested group structure. (But notice we don't do include/osg/Headers, just /include/osg.)
- The source files for each library gets its own (sub)group. Both private headers and implementation files coexist here.
- There are additional targets for loadable libraries (bundles/modules) inside the src/osPlugins directory.
- Applications and Examples both have their own groups and subgroups too which follows the directory structure.
- In fact, separating by Target here might not even work, because all the Public headers in Include are shared by all targets. In Xcode, I don't think you can list the same file in multiple places in the tree. So this could be an actual problem with the current design.
So my initial qualm is the Headers and Sources were arbitrarily separated when nothing in the target description or directory structure told it to separate them.
But I think the directory structure layout might be a better way to go than the target based layout (unless you can sort by target, and then subsort by directory structure, but this might be hard and actually be even more confusing...I would have to see it in action to really know how confusing).
As I said, doing a target based layout is redundant and the project authors usually pick out a directory layout that is sensible for the project. Why contradict them?
The OSG source with Xcode project inside can be found here:
http://www.openscenegraph.org/downloads/snapshots/OSG_OP_OT-1.0.zip [^]
|
|
|
|
(0003519)
|
|
Eric Wing
|
|
2006-01-05 15:51
|
|
Yeah, in Xcode, nothing is really enforced, and things are fairly free form. But there seem to be conventions people are following, partly because of examples and how the templates are setup, partly due to Unix directory structures, and partly due to pragmatic issues about how Xcode works. (One issue about having unnecessary nested groups is that horizontal screen real-estate is at a minimum in the Groups and Files Panel so arbitrarily adding new subgroups like Headers and Source costs a lot of useless space).
So in Xcode, headers are listed; don't remove them. That would be worse.
Currently, you seem to actively seek out files within Targets and split them into:
TargetName/Headers
TargetName/Sources
Instead, you should drop the Headers and Sources subgroups so they just go in:
TargetName
I think order should reflect how they are listed in the CMakeLists.txt and don't sort them or anything.
Now it is okay to have multiple Targets and separate the files based on Target.
TargetName1
File1.h
File1.c
File2.h
File2.c
TargetName2
File3.h
File3.c
File4.h
File4.c
But I think this is a bad idea, particularly for large projects. First, this is redundant because Xcode does this grouping for you if you select the actual Target in the Groups and Files panel. (All the dependent files appear in the top-right "Detail" pane.) And if you expand the target triangle, there is a subgroup called "Compile Sources" which has all the implementation files listed. So what you are doing here may not be as useful as it could be.
Instead, it is also reasonable in Xcode to separate files based on the directory structure of your project. Each group would represent a directory. Obviously, you can get deeply nested groups in Xcode because of this, but since the project is structured this way, it conceptually matches what's really happening so it's not a bad thing. It makes it easy to find the file in the filesystem when you have to do so. I think Xcode users generally understand Unix directory structures enough so that this might actually be the preferred layout.
So for example in OpenSceneGraph, the files are laid out something like:
include/ (these are the Public API headers)
osg/ (For the osg library target)
PositionAttitudeTransform
ref_ptr
osgUtil/ (For the osgUtil library target)
SceneView
src/ (implementation files)
osg/ (for the osg library target)
dxtctool.h (note the private/internal header)
PositionAttitudeTransform.cpp
osgUtil (for the osgUtil library)
SceneView.cpp
TriStrip_tri_stripper.h
osgPlugins/ (not a target itself, but a directory containing loadable module targets)
freetype/ (for the osgDB_freetype.so target)
FreeTypeLibrary.h
FreeTypeLibrary.cpp
jpeg/ (for the osgDB_jpeg.so target)
ReaderWriterJPEG.cpp
applications/ (directory containing app targets)
osgviewer/ (for the osgviewer application target)
osgviewer.cpp
examples/ (directory containing simple example app targets)
osgbillboard/ (for the osgbillboard app target)
osgbillboard.cpp
osgplanets/ (for the osgplanet app target)
osgplanets.cpp
(I would actually encourage you to download the OSG source and check out our existing Xcode project. It would be nice if we could make the CMake generated one resemble it as much as possible.)
So things to note in this project:
- We have multiple targets, but we don't actually sort by target, but follow the directory layout structure. Most large projects seem to layout their directory structures in a sensible way so following them makes sense.
- The directory structure decided to isolate public header files in a directory called "include" (very GNU-ish). They are further subgrouped/separated by each library. Our Xcode project reflects this and has the same nested group structure. (But notice we don't do include/osg/Headers, just /include/osg.)
- The source files for each library gets its own (sub)group. Both private headers and implementation files coexist here.
- There are additional targets for loadable libraries (bundles/modules) inside the src/osPlugins directory.
- Applications and Examples both have their own groups and subgroups too which follows the directory structure.
- In fact, separating by Target here might not even work, because all the Public headers in Include are shared by all targets. In Xcode, I don't think you can list the same file in multiple places in the tree. So this could be an actual problem with the current design.
So my initial qualm is the Headers and Sources were arbitrarily separated when nothing in the target description or directory structure told it to separate them.
But I think the directory structure layout is the better way to go than the target based layout (unless you can sort by target, and then subsort by directory structure, but this might be hard and actually be even more confusing...I would have to see it in action to really know how confusing).
As I said, doing a target based layout is redundant and the project authors usually pick out a directory layout that is sensible for the project. Why contradict them? (And there might be a problem with multiple targets sharing files.)
The OSG source with Xcode project inside can be found here:
http://www.openscenegraph.org/downloads/snapshots/OSG_OP_OT-1.0.zip [^]
(I think next time we need to get the telephone idea rolling. This took too long to type up and I'm not sure if this is even clear :)
|
|
|
|
(0003533)
|
|
Bill Hoffman
|
|
2006-01-09 14:19
|
|
All of that can be done with the SOURCE_GROUP command.
CMake has no knowledge of the directory layout of sources on disk, and I do not have the time to code that up. I can remove the Headers folder and move all of the headers into the Sources folder for the Mac by default.
|
|
|
|
(0003540)
|
|
Eric Wing
|
|
2006-01-10 16:05
|
|
Okay, moving the headers to be with the sources would be a good start.
Just to clarify though, I'm looking at one of my less-trivial CMake generated projects now and it contains multiple (static) library targets and one executable. There is an all encompassing "Sources" group which contains a subgroup for each target.
Each subgroup target contains two sub-groups: "Header Files" and "Source Files".
At the very least, I would recommend putting the header files with "Source Files", but I think it would be better to also drop the group "Source Files", and both the header files and source files get placed in the encompassing target subgroup.
So instead of:
ProjName
Sources
target1
Header Files
foo.h
Source Files
foo.c
target2
...
you get:
ProjName
Sources
target1
foo.h
foo.c
target2
...
As for the (disk) layout, isn't that all implicitly defined by the CMakeLists.txt files and how they reference the files?
I'll look into playing with the SOURCE_GROUP command.
|
|
|
|
(0004729)
|
|
Eric Wing
|
|
2006-08-23 23:52
|
|
Since I'm here, I've been playing with the SOURCE_GROUP command, but so far nothing seems to be showing up for me (Xcode 2.4). OSG has a weird quirk that header files are extension-less, so I've been trying to use the SOURCE_GROUP command to list them, but I don't seem to get results any different than if I omit the command.
Also, I wanted to share some screenshots to give you an idea of what this thread was talking about...
|
|
|
|
(0004730)
|
|
Eric Wing
|
|
2006-08-24 00:02
|
|
Picture 4 is what is currently generated with CMake. (It's still a work in development with a lot to go.) Picture 5 is our current hand-crafted Xcode project.
The thing I wanted to point out is that the Groups and Files panels are the same width (default width) in both pictures. Notice that real-estate is at a premium here. Every nested disclosure level takes a lot of empty space. Also in the CMake generated side, we are getting Source Files and Header Files repeated every place. (You'll also see that my Source_groups command failed to pick up the osgText headers compared to the hand-crafted version).
In the hand-crafted version, we separated public headers (called include to match the directory structure somewhat) and sources (and private headers) into two different categories from the root. This has served us well and I would like to try to reproduce this with CMake. As I see it, Source_Groups must let us specify all the public headers into the include/osg* groups, and CMake must remove the generation of "Source Files" and "Header Files" groups at every level.
|
|
|
|
(0041305)
|
|
Kitware Robot
|
|
2016-06-10 14:27
|
|
Resolving issue as `moved`.
This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page. |
|
Picture 4.png (204,210) 1969-12-31 19:00
