Hello Gerrit,
Gerrit Voß wrote:
> just to keep it a little on track. This is mainly about windows
> especially with multi target (>2) visual studio (mtvs) solutions. You
> have to forget the simplicity of the unix makefile variants.
ok.
> On Fri, 2009-06-19 at 09:42 -0500, Carsten Neumann wrote:
>> Gerrit Voß wrote:
>>> not yet, we usually only convert a single main file to the app, all
>>> the rest is build as libs. I wanted to work on external stuff anyway
>>> so that you can easily create and import the OpenSG cmake settings,
>>> in particular the compiler settings.
>>> I have some preliminary helper functions. I'll see if I can add
>>> this feature.
>> hm, cmake modules (the FindFoo.cmake files used by find_package) can
>> operate in two modes [1], most are like FindOpenSG.cmake written to
>> search all necessary information and deduce settings from what they
>> discover.
>
> IMHO not quite, the simplistic just set _INCLUDE _LIBRARIES and
> _LIBRARY_DIRS does not work well with windows mtvs solutions, especially
> with custom build targets and the 'set all to the one that was' found
> approach.
ok. Have you found other cmake modules that handle this correctly? The
ones I looked at so far were not really doing much to actively handle
this and I'm uncertain what the "official" approach is - at least the
distinction between debug and release runtime affects basically all libs
on windows, we just have a few more variants ;)
>> The other mode just attempts to locate a file named
>> FooConfig.cmake or foo-config.cmake and take all settings from there.
>> Perhaps that is the way to go to export all the information you want
>> from the build?
>
> hmm, not sure if I really want to go there as having two versions
> of the same thing is usually a consistency nightmare.
yes, sorry if this was not clear, I meant to ask if changing the way
FindOpenSG.cmake works would make sense. Currently it is simply
installed during build, i.e. it does not contain any information
specific to the build, but instead it gathers all info when it runs and
searches for the libraries/headers.
> And there is one thing that applies to all platforms, it is not just
> about getting a few settings. Getting file handling is IMHO essential.
> We can't really tell people, use fcd2code to generate containers and
> than don't provide the means to do so reasonable efficiently.
> At least with the native build system there should be an 'reasonably'
> easy way to do so.
ok, how about a function/macro, that given an .fcd returns the files
fcd2code generates and a second one that hides the details of the
ADD_CUSTOM_COMMAND call? That should make it pretty straightforward to
integrate this preprocessing step into any cmake based build.
The thing I'm trying to avoid here is a too tight integration into
OpenSG's own build system. I think that would be a disservice as it
would force our build system onto users and (perhaps worse) require them
to understand how our build works.
If the goal is to provide enough information and hide complex command
lines with some functions exported from FindOpenSG.cmake I'm all for it.
It should follow the spirit of existing cmake modules as much as
possible otherwise I fear it will be considered arcane and simply ignored.
Cheers,
Carsten
------------------------------------------------------------------------------
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
