<br>Yes. That is what I am currently trying to implement. <br>
( In first draft I use UseNepomuk<Name>.cmake, but
*Config[Version].cmake is much more flexible as it allows to write both
find_package(Nepomuk COMPONENTS <n1> <n2> ) and
find_package(NepomukCore), thank you for that idea :) )<br><br>Is it ok with everyone, I will stop on this variant.<br><br><div class="gmail_quote">On Sat, Sep 3, 2011 at 12:46 PM, Sebastian Trüg <span dir="ltr"><<a href="mailto:trueg@kde.org">trueg@kde.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hi Artem,<br>
<br>
did I understand correctly: having the *Config[Version].cmake files but<br>
use them in a dedicated FindNepomuk.cmake which supports components?<br>
That sounds like a powerful solution to me...<br>
</blockquote><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Cheers,<br>
<font color="#888888">Sebastian<br>
</font><div><div></div><div class="h5"><br>
On 09/02/2011 11:28 PM, Artem Serebriyskiy wrote:<br>
> Well, as we now have several repositories and libraries, it should be<br>
> NepomuCoreConfig.cmake<br>
> NepomukUiConfig.cmake<br>
> NepomukSomeOtherModule.cmake and so on<br>
><br>
> and this may result in code like<br>
> find_package(NepomukUI) // Implies finding NepomukCore<br>
> find_package(<br>
> NepomukSomeOtherModule) // Implies finding NepomukCore, but doesn't<br>
> imply finding NepomukUI, so we need previous line<br>
><br>
> Good things is that we can request specific versions for every library(<br>
> aka module) and so on. Bad things, as for me, are that when number of<br>
> modules more then 3, the code looks dirty - I personally would prefer<br>
> one find_package with COMPONENTS in such situation rather then 4 lines<br>
> with find_package..<br>
><br>
> Anyway, currently there are only 2 main modules( aka libraries) so it is<br>
> not the case.<br>
><br>
> CMake scripting is no problem for me, so I think we can/should choose<br>
> variant that best fits our needs and offer good interface for the<br>
> programmes using Nepomuk, and I will implement it( if necessary, of<br>
> course).<br>
><br>
> P.S. If you are concerned about internals of the script, then current<br>
> draft implementation just loads Nepomuk<ModuleName>Config.cmake for<br>
> every requested component by itself. The question is mainly about<br>
> interface for the Nepomuk-using programmers.<br>
><br>
> P.P.S. Sorry, forget to send to mailing list.<br>
><br>
><br>
><br>
> On Sat, Sep 3, 2011 at 12:56 AM, Sebastian Trüg <<a href="mailto:trueg@kde.org">trueg@kde.org</a><br>
</div></div><div><div></div><div class="h5">> <mailto:<a href="mailto:trueg@kde.org">trueg@kde.org</a>>> wrote:<br>
><br>
> How about just doing it with a NepomukConfig.cmake and a<br>
> NepomukConfigVersion.cmake. AFAIK that is the simplest solution and does<br>
> not require any fancy script writing.<br>
> I am not sure if it is enough in all situations though...<br>
><br>
> Examples can be found in sdo, nepomukannotation, scribo, and others, I<br>
> think Akonadi does it, too.<br>
><br>
> Cheers,<br>
> Sebastian<br>
><br>
> On 09/02/2011 10:24 PM, Artem Serebriyskiy wrote:<br>
> > Hi.<br>
> ><br>
> > I am trying to provide a replacement for FIndNepomuk.cmake that will<br>
> > work with new Nepomuk layout . And I have a question for desired<br>
> API of<br>
> > the script. In current draft all modules are treated as components.<br>
> > Examples:<br>
> > 1. find_package(Nepomuk COMPONENTS core ui ) will try to found all<br>
> > required components and will set general variables NEPOMUK_FOUND,<br>
> > _LIBRARIES, _INCLUDE_DIRS and component-specific variables<br>
> > NEPOMUK_${COMPONENT}_FOUND, NEPOMUK_${COMPONENT}_LIBRARY,<br>
> _INCLUDE_DIRS<br>
> > for each component ( expands to NEPOMUK_CORE_LIBRARY,<br>
> > NEPOMUK_UI_LIBRARY) etc.<br>
> ><br>
> > 2. find_package(Nepomuk) will try to found all available modules<br>
> of the<br>
> > Nepomuk on the system and for every found module will set variables<br>
> > mentioned above. Global ones are combination of all<br>
> component-specific,<br>
> > and NEPOMUK_FOUND is set to true if at least any package was<br>
> discovered.<br>
> ><br>
> > Downside of this solution is that we loose ability to request version<br>
> > for component, so it will require to sync versions at least<br>
> between main<br>
> > modules.<br>
> ><br>
> > Is this acceptable ?<br>
> > Any comments and suggestions are welcome.<br>
> ><br>
> > --<br>
> > Sincerely yours,<br>
> > Artem Serebriyskiy<br>
><br>
><br>
><br>
><br>
> --<br>
> Sincerely yours,<br>
> Artem Serebriyskiy<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Sincerely yours,<br>Artem Serebriyskiy<br>