Re: [Maya2osg-users] Problem with source groups in CMakeLists.txt for VC9

[Javier T. <jav...@gm...>]

  Hi,

On Fri, May 13, 2011 at 6:05 PM, Jean-Sébastien Guay
<jea...@cm...> wrote:
>>    Yes, I tested it in Visual Studio 2010 Express, and it worked there.
>> But I have to tweak a bit the filter option to make it work. It's a
>> bit tricky.
>
> What do you mean when you say "tweak the filter option"?

  Well, that I have to try several times until I get it working. But
the problem was probably between the keyboard and the chair :)

  However, I have the feeling that the regex matching order when
defining several lines does not work as described in the
documentation. Anyway, it is just a cosmetic issue, it is really not a
big issue if we have to put them all in the same VS project folder.
Just thought that separating them in sections would help to locate the
source files in the project.

>>    I know how to make the debug targets link with debug libraries and
>> release targets with release libraries. But, when I am using
>> RelWithDebInfo, it considers it "optimized" and links it with the
>> Release version (not the RelWithDebInfo). Is there any easy way (not
>> populating the script with lots of conditionals and manually adding
>> suffixes that are already defined) to make each target link with the
>> corresponding ones?
>
> I have no idea, honestly... I admit it's weird that the LINK_LIBRARIES
> command has 2 hard-coded modes, debug and optimized, when there are 4
> configurations possible, debug, release, release with debug info and min
> size release.

  OK. That's what I thought. I had to ask just in case there was an
evident way I were missing.

> Theoretically, if what you want is to be able to debug into OSG with
> your RelWithDebInfo build of the plugin, you could build OSG in

  Actually, it is not for the Maya2OSG plug-in, it is for other
project I am working on, where I have several libraries in different
CMake trees and most of them linking to OSG. I have to test it running
in high performance (so Debug is not an option), and I need to
remotely debug it when there is a problem, so RelWithDebInfo (and
activating core dumping) is perfect for that.

> RelWithDebInfo, setting the suffix to empty for that configuration (in
> advanced settings in OSG's CMake), then your RelWithDebInfo DLLs will
> have the same filenames as the Release ones. Then you just have to
> replace the Release DLL files with the RelWithDebInfo ones, and they'll
> be picked up when the plugin is loaded. Since RelWithDebInfo is
> binary-compatible with Release, you can use either interchangeably.
>
> Sure, it's a workaround and not a fix, but it might get you where you
> want to go.

  Thanks for the tip. I would prefer all of them to coexist, but this
seems to be the best option then. Thank you again for your CMake
support.


-- 
Javier Taibo