CMake build system for Cthugha *looking for testers*
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 58
- Contact:
Re: CMake build system for Cthugha *looking for testers*
I don't know, I picked those settings from the old build systems and didn't investigate them any further. Do you have any insights, for what or when these are needed and how we could decide if to include them or not?
- cdleonard
- Goblin
- Posts: 266
- Joined: Thu May 31, 2007 9:45 am
Re: CMake build system for Cthugha *looking for testers*
I finally got around to creating a custom build of ogre using only CMake (on windows). It was really easy to do; except for the inevitably insane compile times. Some feedback:
- Release and RelWithDebInfo overlap both in the build and installed output. It would make sense for each build config to have a directory in output/bin. This wouldn't work with lib files; perhaps lib files could go in output/lib/$config as well?
- Include files used to be in output/include (for a SDK); now they're in output/include/OGRE/. Presumably the structure should be as similar to the current SDK as possible?
- PDB files are not installed. While they're too large for a regular SDK they are very useful in a custom build. This should be an option.
- Plugin headers are no longer installed; not even in include/opt like in the current SDK. The lib files are still there.
- OgreGUIRenderer* is now called CEGUIOgreRenderer*.
- Stuff like resources.cfg is copied to the output by default. Ignoring it is easy enough.
I'm not sure if stuff inside CMAKE_INSTALL_PREFIX is intended to look exactly like an 1.6 sdk; but it's something worth considering.
On a completely unrelated note: CEGUI-OGRE.pc now seems to work in linux.
- Release and RelWithDebInfo overlap both in the build and installed output. It would make sense for each build config to have a directory in output/bin. This wouldn't work with lib files; perhaps lib files could go in output/lib/$config as well?
- Include files used to be in output/include (for a SDK); now they're in output/include/OGRE/. Presumably the structure should be as similar to the current SDK as possible?
- PDB files are not installed. While they're too large for a regular SDK they are very useful in a custom build. This should be an option.
- Plugin headers are no longer installed; not even in include/opt like in the current SDK. The lib files are still there.
- OgreGUIRenderer* is now called CEGUIOgreRenderer*.
- Stuff like resources.cfg is copied to the output by default. Ignoring it is easy enough.
I'm not sure if stuff inside CMAKE_INSTALL_PREFIX is intended to look exactly like an 1.6 sdk; but it's something worth considering.
On a completely unrelated note: CEGUI-OGRE.pc now seems to work in linux.
-
- Bugbear
- Posts: 812
- Joined: Thu Dec 09, 2004 2:51 am
- x 42
Re: CMake build system for Cthugha *looking for testers*
@CABAListic,
No insight, just curious, I don't remember -DFREEIMAGE_LIB being included on the old autotools build ( I could be wrong).
No insight, just curious, I don't remember -DFREEIMAGE_LIB being included on the old autotools build ( I could be wrong).
-
- Bugbear
- Posts: 812
- Joined: Thu Dec 09, 2004 2:51 am
- x 42
Re: CMake build system for Cthugha *looking for testers*
Not too sure if I've missed an update but the CEGUI-OGRE pkconfig file appears to point to non-existant directory. The OgreCEGUI headers appear to be installed in the main Ogre/include dir.
Code: Select all
Cflags: -I${includedir}/OGRE/CEGUIRenderer
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 58
- Contact:
Re: CMake build system for Cthugha *looking for testers*
Actually, RelWithDebInfo and MinSizeRel are currently broken on Windows for those reasons. It takes a bit of effort to get all cfg files etc. installed into the correct directories which is way I've done it only for the standard Debug/Release builds so far. I could tell CMake to exclude the rest of the configurations for now; in fact I'm not even sure if RelWithDebInfo does anything useful for MSVC.cdleonard wrote:I finally got around to creating a custom build of ogre using only CMake (on windows). It was really easy to do; except for the inevitably insane compile times. Some feedback:
- Release and RelWithDebInfo overlap both in the build and installed output. It would make sense for each build config to have a directory in output/bin. This wouldn't work with lib files; perhaps lib files could go in output/lib/$config as well?
I assume with output you mean installation? It's been a while since I used an SDK, were they really just in include? I think this is not exactly tidy, seeing as how there have to be a couple of dependency headers in there, as well. In any case, I use include/OGRE because this is what Unix needs. I try to keep the platforms in line as much as I can to avoid endless amounts of if cases.- Include files used to be in output/include (for a SDK); now they're in output/include/OGRE/. Presumably the structure should be as similar to the current SDK as possible?
@dermont: Yeah, I intend to change that (i. e. move the include files to that directory), it's more tidy that way.
CMake does not know about pdb files and offers no option to get at them. It is probably relatively straight-forward to collect them manually, but then again you *can* use the build directory directly without install (at least the CMake FindOGRE script can handle that case) which might be beneficial if you actually want to debug Ogre.- PDB files are not installed. While they're too large for a regular SDK they are very useful in a custom build. This should be an option.
Far as I remember plugin headers were never part of the official SDKs. But an according install option is in fact on my todo.- Plugin headers are no longer installed; not even in include/opt like in the current SDK. The lib files are still there.
And rightly so! If I'm not mistaken, CEGUI calls its renderers CEGUIOpenGLRenderer etc., so CEGUIOgreRenderer fits that scheme, while OgreGUIRenderer doesn't even say it's CEGUI. Besides, it's always been called CEGUIOgreRenderer on Linux builds, so this is another case of getting the platforms in line.- OgreGUIRenderer* is now called CEGUIOgreRenderer*.
You mean if samples are not to be installed?- Stuff like resources.cfg is copied to the output by default. Ignoring it is easy enough.
I'm aiming close, but since it's going to be a new Ogre release I think we can give some rope for a few things. Mostly it is modelled after the old SDKs, though.I'm not sure if stuff inside CMAKE_INSTALL_PREFIX is intended to look exactly like an 1.6 sdk; but it's something worth considering.
- CrazyEddie
- Goblin
- Posts: 228
- Joined: Thu Feb 12, 2004 10:03 am
- Location: Workin' on someting cool
- x 1
- Contact:
Re: CMake build system for Cthugha *looking for testers*
Just popping in here to say that there is/was a disparity between Win32 and other systems as regards to CEGUI renderer naming, however we are also addressing this issue in future releases to unify the naming of modules across all platforms. So this change is, in my opinion, definitely the Right Thing™ to be doing.CABAListic wrote:And rightly so! If I'm not mistaken, CEGUI calls its renderers CEGUIOpenGLRenderer etc., so CEGUIOgreRenderer fits that scheme, while OgreGUIRenderer doesn't even say it's CEGUI. Besides, it's always been called CEGUIOgreRenderer on Linux builds, so this is another case of getting the platforms in line.- OgreGUIRenderer* is now called CEGUIOgreRenderer*.
CE.
Creator of the CEGUI library.
-
- Gnoblar
- Posts: 21
- Joined: Wed Sep 17, 2008 1:47 pm
Re: CMake build system for Cthugha *looking for testers*
Hi.
I built Ogre on Linux about a month ago using CMake and everything went smooth.
Tonight I built it and I have a problem with the OpenGL plugin. An undefined symbol, XGetProcAddressARB. I know it is in
OpenGL and I have changed my libraries since last time so I plan to track this down. I just wanted to mention it in case it is
a known issue and not something on my machine.
Also, I have added the OpenGL ES render system to CMake on my machine. So far only tested on linux. Once I get my
problems straightened out here I am going to copy it over to my Windows box and try it there. I don't have a Mac to test on.
Thanks.
David.
I built Ogre on Linux about a month ago using CMake and everything went smooth.
Tonight I built it and I have a problem with the OpenGL plugin. An undefined symbol, XGetProcAddressARB. I know it is in
OpenGL and I have changed my libraries since last time so I plan to track this down. I just wanted to mention it in case it is
a known issue and not something on my machine.
Also, I have added the OpenGL ES render system to CMake on my machine. So far only tested on linux. Once I get my
problems straightened out here I am going to copy it over to my Windows box and try it there. I don't have a Mac to test on.
Thanks.
David.
- Kojack
- OGRE Moderator
- Posts: 7157
- Joined: Sun Jan 25, 2004 7:35 am
- Location: Brisbane, Australia
- x 534
Re: CMake build system for Cthugha *looking for testers*
I only skimmed the previous pages and didn't see any mention of this. When I get the latest svn of ogre and use cmake to generate a visual studio 2008 solution, it marks every single header in every project as "exclude from build". Of course that file property only applies to cpps files and is ignored for headers, so everything builds fine, but it means I've got hundreds of red warning icons all over my solution browser.
The absolute file name generation for everything is rather annoying, but I guess I can expand my Ruby script to rip all that out (I already use it to automatically modify ogre's projects to suit my framework's directory structure and make the build neater by isolating most temporary data in a single disposable directory instead of spread throughout the project directories).
Besides that, it works fine so far.
The absolute file name generation for everything is rather annoying, but I guess I can expand my Ruby script to rip all that out (I already use it to automatically modify ogre's projects to suit my framework's directory structure and make the build neater by isolating most temporary data in a single disposable directory instead of spread throughout the project directories).
Besides that, it works fine so far.
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 58
- Contact:
Re: CMake build system for Cthugha *looking for testers*
The "exclude from build" issue probably needs to be raised with the CMake team, this is not our doing.
As for the absolute file name generation: CMake provides an option CMAKE_USE_RELATIVE_PATHS. You could test that one, I think sinbad would be interested in your results, too, as this might be a way to get pregenerated build solutions for the SDK releases, too. Then again, for non-shared project files, what exactly annoys you about the absolute path usage?
As for the absolute file name generation: CMake provides an option CMAKE_USE_RELATIVE_PATHS. You could test that one, I think sinbad would be interested in your results, too, as this might be a way to get pregenerated build solutions for the SDK releases, too. Then again, for non-shared project files, what exactly annoys you about the absolute path usage?
- Kojack
- OGRE Moderator
- Posts: 7157
- Joined: Sun Jan 25, 2004 7:35 am
- Location: Brisbane, Australia
- x 534
Re: CMake build system for Cthugha *looking for testers*
I make multiple copies of ogre when I'm experimenting with stuff in the source, and I carry several solutions around on a portable hard drive so I can work on stuff at home or work, on any of a hundred or so pcs I might end up on that day. Having to regenerate every ogre project file and rebuild the whole thing (and install cmake where ever I am) when all I had to do in the past was press Control-C, Control-V is a bit annoying.Then again, for non-shared project files, what exactly annoys you about the absolute path usage?
Plus I have both windows xp and vista on my home pc with visual studio, with this I can't build the same solution from both of them, because the drive letters are different.
Looks like the excluded header files problem is fixed in cmake 2.6.4 RC1: http://www.mail-archive.com/cmake@cmake ... 20247.html
But I haven't tested it.
I'll give CMAKE_USE_RELATIVE_PATHS a try, if I can find where to put it. I've never used cmake before this.
- Kojack
- OGRE Moderator
- Posts: 7157
- Joined: Sun Jan 25, 2004 7:35 am
- Location: Brisbane, Australia
- x 534
Re: CMake build system for Cthugha *looking for testers*
I downloaded cmake 2.7 (cvs nightly snapshot) and it fixed the header problem.
I also tried the CMAKE_USE_RELATIVE_PATHS. It makes most things relative (includes, libs, etc) but it leaves pdb files, command and working directory as absolute paths. I built ogre in release, closed it, renamed the base directory, opened it and tried running an app, it wanted to rebuild everything. I renamed the directory back and it ran without rebuild. So it's still absolute path locked even though pdbs aren't built in release mode and command/working dir don't affect builds, just the final runtime. I went through the project files in notepad++ trying to find where else it's doing this, haven't found it yet.
I also noticed that now the ogre resources.cfg file is generated by cmake with absolute paths (even with CMAKE_USE_RELATIVE_PATHS). So not only is the ogre source not relocatable, but even the bin directory is now hard coded to not work if you move it because it can't find the media directory.
I also tried the CMAKE_USE_RELATIVE_PATHS. It makes most things relative (includes, libs, etc) but it leaves pdb files, command and working directory as absolute paths. I built ogre in release, closed it, renamed the base directory, opened it and tried running an app, it wanted to rebuild everything. I renamed the directory back and it ran without rebuild. So it's still absolute path locked even though pdbs aren't built in release mode and command/working dir don't affect builds, just the final runtime. I went through the project files in notepad++ trying to find where else it's doing this, haven't found it yet.
I also noticed that now the ogre resources.cfg file is generated by cmake with absolute paths (even with CMAKE_USE_RELATIVE_PATHS). So not only is the ogre source not relocatable, but even the bin directory is now hard coded to not work if you move it because it can't find the media directory.
- jacmoe
- OGRE Retired Moderator
- Posts: 20570
- Joined: Thu Jan 22, 2004 10:13 am
- Location: Denmark
- x 179
- Contact:
Re: CMake build system for Cthugha *looking for testers*
Er, I did download the dependencies - and first I thought I would put them in my new build folder, but I discovered that the CMake scripts had a hardcoded semi-relative path - so this should probably be fixed?
I unzipped the dependencies into ogre_src folder and configured.
Everything was dandy, except for this:
I entered the Advanced View and fixed it.
I unzipped the dependencies into ogre_src folder and configured.
Everything was dandy, except for this:
Pretty clever, but that's not what I want.Found CEGUI: optimized;D:/OgreSDK/lib/CEGUIBase.lib;debug;D:/OgreSDK/lib/CEGUIBase_d.lib
Looking for OIS...
Found OIS: optimized;D:/OgreSDK/lib/OIS.lib;debug;D:/OgreSDK/lib/OIS_d.lib
I entered the Advanced View and fixed it.
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 58
- Contact:
Re: CMake build system for Cthugha *looking for testers*
The dependency directory in the source should always take precedence (though I'm going to add a few more spots, I guess). However, if I understood you right, you first put them in the build tree, then run CMake, right? In that case, it didn't find them in the dependencies dir, therefore looked further and found them at the SDK dir. So that's it, the search results are cached, so they won't be researched unless you explicitly reset their values to "NOTFOUND".
@Kojack: Well, I'm sorry, but I guess you've hit the limit of CMake. I see nothing I could do to improve upon that
I wonder, though, if you copied your build dir, but would rerun CMake on it, if it would still try to rebuild everything? You probably have to delete CMake's cache (in cmake-gui, it's a menu option) and redo the CMake config, but it might still be an improvement for you, or so I hope.
@Kojack: Well, I'm sorry, but I guess you've hit the limit of CMake. I see nothing I could do to improve upon that
I wonder, though, if you copied your build dir, but would rerun CMake on it, if it would still try to rebuild everything? You probably have to delete CMake's cache (in cmake-gui, it's a menu option) and redo the CMake config, but it might still be an improvement for you, or so I hope.
- jacmoe
- OGRE Retired Moderator
- Posts: 20570
- Joined: Thu Jan 22, 2004 10:13 am
- Location: Denmark
- x 179
- Contact:
Re: CMake build system for Cthugha *looking for testers*
In my case, CMake found them before I even downloaded the dependencies.CABAListic wrote:The dependency directory in the source should always take precedence (though I'm going to add a few more spots, I guess). However, if I understood you right, you first put them in the build tree, then run CMake, right? In that case, it didn't find them in the dependencies dir, therefore looked further and found them at the SDK dir. So that's it, the search results are cached, so they won't be researched unless you explicitly reset their values to "NOTFOUND".
I will try again with a totally clean system.
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
- Kojack
- OGRE Moderator
- Posts: 7157
- Joined: Sun Jan 25, 2004 7:35 am
- Location: Brisbane, Australia
- x 534
Re: CMake build system for Cthugha *looking for testers*
Oh well. At least I've already got a Ruby script which will help, I'll just have to use it to post process every ogre project to strip out absolute directories. While I'm at it, I can get rid of one of my pet peeves with 99% of source code these days: intermediate build data being mixed in with projects. I do that to ogre for my own framework already, but I might as well do it for pure ogre solutions too.
Why is cmake so obsessed with hard coding absolute directories everywhere? It even embeds version specific absolute directories of itself (in my case C:\Program Files (x86)\CMake 2.7\bin\cmake.exe) inside of every project as a custom build rule for timestamp checking, installing and packaging. Sounds like upgrading to a new version of cmake without leaving the old one installed would break all existing projects until you re-ran cmake on them.
Why is cmake so obsessed with hard coding absolute directories everywhere? It even embeds version specific absolute directories of itself (in my case C:\Program Files (x86)\CMake 2.7\bin\cmake.exe) inside of every project as a custom build rule for timestamp checking, installing and packaging. Sounds like upgrading to a new version of cmake without leaving the old one installed would break all existing projects until you re-ran cmake on them.
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 58
- Contact:
Re: CMake build system for Cthugha *looking for testers*
For one thing probably because it is designed under the specific assumption that CMake *is* the build system, and the generated native toolchains are only the means of the build which are generated according to the specific environment. CMake is supposed to deal with differing directory layouts when it comes to dependencies etc., which breaks down again if you share the created native build systems. If you really want to do that, then CMake can't offer any advantage over a native build system in the first place, I guess.Kojack wrote:Why is cmake so obsessed with hard coding absolute directories everywhere? It even embeds version specific absolute directories of itself (in my case C:\Program Files (x86)\CMake 2.7\bin\cmake.exe) inside of every project as a custom build rule for timestamp checking, installing and packaging. Sounds like upgrading to a new version of cmake without leaving the old one installed would break all existing projects until you re-ran cmake on them.
Then, of course, there are paths which cannot be given relatively, particularly when they are on different drives. And since it's more effort to find relative paths it might be that CMake doesn't really bother.
- jacmoe
- OGRE Retired Moderator
- Posts: 20570
- Joined: Thu Jan 22, 2004 10:13 am
- Location: Denmark
- x 179
- Contact:
Re:
Used the BoostPro installer. CMake finds BOOST_INCLUDE_DIR, but that's it. I tried to tell it where the threading libs are, but it won't take it. It erases my entry with Boost_THREAD_LIBRARY_DEBUG-NOTFOUND.CABAListic wrote:The FindBoost package is already used, it's implicitly called in the FindDependencies script. If it cannot find boost, I'm afraid you'll have to provide the paths yourself in the CMake configuration.
I've installed the entire Boost collection of libraries, in all modes, so the libs are definitely there.
IMO, it should work right out of the box when using the Boost installer.
I changed the default install location of Boost, moved it out from program files/boost to C:/boost - could that be the issue?
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
- jacmoe
- OGRE Retired Moderator
- Posts: 20570
- Joined: Thu Jan 22, 2004 10:13 am
- Location: Denmark
- x 179
- Contact:
Re: CMake build system for Cthugha *looking for testers*
Other than that: It builds!
I really like this - thanks a lot CABAListic!
I really like this - thanks a lot CABAListic!
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 58
- Contact:
Re: CMake build system for Cthugha *looking for testers*
Hm, I'll look into it. Out of curiosity, since I'm on Linux right now, does the Boost installer set the Boost_ROOT environment variable? Because if not, then yes, changing the default install location may set off the find script - after all, it does not possess psychic abilities
- jacmoe
- OGRE Retired Moderator
- Posts: 20570
- Joined: Thu Jan 22, 2004 10:13 am
- Location: Denmark
- x 179
- Contact:
Re: CMake build system for Cthugha *looking for testers*
It was psychic enough to know where Boost was installed -> C:\boost\boost_1_38\boost - ie it filled out the BOOST_INCLUDE_DIR var, but failed to find any thread libs. Strange, if you ask me.CABAListic wrote:changing the default install location may set off the find script - after all, it does not possess psychic abilities
I can't see any Boost variable - it might be in the registry somewhere, I guess.
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
- jacmoe
- OGRE Retired Moderator
- Posts: 20570
- Joined: Thu Jan 22, 2004 10:13 am
- Location: Denmark
- x 179
- Contact:
Re: CMake build system for Cthugha *looking for testers*
It's in HKLM/SOFTWARE/boostpro.com/1.38/InstallRoot.
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 58
- Contact:
Re: CMake build system for Cthugha *looking for testers*
I'll take a look. Though, as I said, the FindBoost script is curtesy of CMake, and I'd like to keep it that way if at all possible. If it doesn't look for the registry values, perhaps I can inject them from the outside...
- jacmoe
- OGRE Retired Moderator
- Posts: 20570
- Joined: Thu Jan 22, 2004 10:13 am
- Location: Denmark
- x 179
- Contact:
Re: CMake build system for Cthugha *looking for testers*
I'll try using BOOSTROOT, BOOST_INCLUDEDIR and BOOST_LIBRARYDIR - three environment vars which the CMake FIND_BOOST script checks for.
Strange that it managed to find BOOSTROOT and BOOST_INCLUDEDIR, as I don't see any environment vars in my list. Maybe a reboot is in order?
I'll report back later.
<edit>
Aw, right: It finds Boost because I moved it to C:\Boost which is a hardcoded possible Boost location in the CMake script.
</edit>
Strange that it managed to find BOOSTROOT and BOOST_INCLUDEDIR, as I don't see any environment vars in my list. Maybe a reboot is in order?
I'll report back later.
<edit>
Aw, right: It finds Boost because I moved it to C:\Boost which is a hardcoded possible Boost location in the CMake script.
</edit>
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
-
- Bugbear
- Posts: 812
- Joined: Thu Dec 09, 2004 2:51 am
- x 42
Re: CMake build system for Cthugha *looking for testers*
After updating svn it appears that on Linux for a debug build the library names /pkgconfig files are suffixed with "_d", e.g.
I'm assuming the above is to allow side by side installation of release/ debug builds.
How does the above work when building, say for example ogreaddons, projects in debug where the autotool builds are set up to work against the "OGRE.pc" pkgconfig file?
Do I have to update these to specify a debug build option to use "OGRE_d.pc" (yuck)? If so can I just pass debug flags to CXX_FLAGS_RELEASE to replicate a debug build to avoid this?
Code: Select all
OGRE_d.pc
libOgreMain_d.so.1.7.1
How does the above work when building, say for example ogreaddons, projects in debug where the autotool builds are set up to work against the "OGRE.pc" pkgconfig file?
Do I have to update these to specify a debug build option to use "OGRE_d.pc" (yuck)? If so can I just pass debug flags to CXX_FLAGS_RELEASE to replicate a debug build to avoid this?
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 58
- Contact:
Re: CMake build system for Cthugha *looking for testers*
You can manually rename the OGRE_d.pc file, if you want. They are indeed named like that to allow side-by-side installation. Otherwise, yes, you have to update the according projects and no, setting cxx flags won't help because the libraries have a different suffix in debug builds.