Uniform directory structure for both SDK and source release

[nikki]

Today on IRC, someone had a problem with the AppWizard because it was built for the SDK directory structure and he had the Ogre source one. The last time I checked on Windows, the SDK just had 'include' and 'lib' directories directly under the root Ogre directory, whereas in source the main headers were in 'OgreMain/include' and libraries got copied to 'lib' under root. This is understandable, because the source distribution also has the source code and it has to be a bit organised, we can't allow OgreMain, the PlugIns and the Tools to mix.

However, it would be nice to have a common directory structure between SDK and source release, so that AppWizards or build scripts don't have to bother which release one is using. You could have a post-build process to copy the headers over to 'include' under root or something, or may be you could think of something better. Under Linux, this isn't much of a problem since most people are going to build from source and install to /usr/local prefix anyway. On Windows, it could be a little frustrating.

If this discrepancy in the directory structure has a valid reason, I'm willing to agree if you explain it.

[CABAListic]

Well, this is where the CMake build system would come to rescue. With it, you would basically build your own SDK, the source directory is no longer touched, and at the end you get a clean install directory of your choice. Any future SDK package would just be a copy of this install directory, so the structures would be exactly identical.

[jacmoe]

Today on IRC, someone had a problem with the AppWizard because it was built for the SDK directory structure and he had the Ogre source one.

That's can't be a problem because there are AppWizards for both SDK and source. I guess that someone used the wrong wizard.

[nikki]

Today on IRC, someone had a problem with the AppWizard because it was built for the SDK directory structure and he had the Ogre source one.

That's can't be a problem because there are AppWizards for both SDK and source. I guess that someone used the wrong wizard.

Ahh... I'm not familiar with the AppWizards because I never used them.

[sinbad]

The SDK is a different structure precisely because it's simplified. The source release *has* to have a deeper directory structure because it contains more. You can't flatten the source release, and making the SDK that structure would confuse people with a zillion empty directories.

[nikki]

The SDK is a different structure precisely because it's simplified. The source release *has* to have a deeper directory structure because it contains more. You can't flatten the source release, and making the SDK that structure would confuse people with a zillion empty directories.

I was thinking the same thing.

So how should build-scripts/project files be made independent of the release (SDK/source) of Ogre one uses? The problem is often seen in Visual C++ projects on Windows (like, the OgreBullet ones).

[jacmoe]

You could do it by providing projects for SDK and source, or you could do it by providing one project with different configurations.
Or by a script which creates a project based on user input.
If you are using a build script generator like premake, bakefile or cmake, you don't have to worry about it, much.

[CABAListic]

The SDK is a different structure precisely because it's simplified. The source release *has* to have a deeper directory structure because it contains more. You can't flatten the source release, and making the SDK that structure would confuse people with a zillion empty directories.

I was thinking the same thing.

So how should build-scripts/project files be made independent of the release (SDK/source) of Ogre one uses? The problem is often seen in Visual C++ projects on Windows (like, the OgreBullet ones).

Because CMake has an additional INSTALL step which conventional Visual C++ projects don't provide. The project is built from the source tree into a specified build tree (the source tree is, in fact, never touched, not a single file is generated in there, unless you specify the source tree as the build tree). From there, all files you need for everyday use of Ogre (i. e. the compiled libraries, plugins, headers etc.) are copied to the install directory which would then basically become your Ogre installation that you can link your Ogre projects to. And this install directory *can* look like the SDK (or at least I don't see why it couldn't). Just try it, I'm looking for testers, anyway

[nikki]

The SDK is a different structure precisely because it's simplified. The source release *has* to have a deeper directory structure because it contains more. You can't flatten the source release, and making the SDK that structure would confuse people with a zillion empty directories.

I was thinking the same thing.

So how should build-scripts/project files be made independent of the release (SDK/source) of Ogre one uses? The problem is often seen in Visual C++ projects on Windows (like, the OgreBullet ones).

Because CMake has an additional INSTALL step which conventional Visual C++ projects don't provide. The project is built from the source tree into a specified build tree (the source tree is, in fact, never touched, not a single file is generated in there, unless you specify the source tree as the build tree). From there, all files you need for everyday use of Ogre (i. e. the compiled libraries, plugins, headers etc.) are copied to the install directory which would then basically become your Ogre installation that you can link your Ogre projects to. And this install directory *can* look like the SDK (or at least I don't see why it couldn't). Just try it, I'm looking for testers, anyway

That's a bit like make install and the configure script prefix, isn't it?

[CABAListic]

Yes, it is - in fact, on Linux it *is* make install

[jacmoe]

Yes, it is - in fact, on Linux it *is* make install

One of the great things about cmake is that it uses native build tools.