[Nepomuk] CMake for Nepomuk in 5.0

[Sebastian Trüg]

great, thanks a lot for taking care of this. :)

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