[prev in list] [next in list] [prev in thread] [next in thread]
List: nepomuk
Subject: Re: [Nepomuk] CMake for Nepomuk in 5.0
From: Artem Serebriyskiy <v.for.vandal () gmail ! com>
Date: 2011-09-03 9:25:01
Message-ID: CAJU16cNtr3ZQxPWDF0OQ0qqp6-Gcm8epN1rQ9XMOONPDJOcz2Q () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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@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@kde.org
> > <mailto:trueg@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
[Attachment #5 (text/html)]
<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>
_______________________________________________
Nepomuk mailing list
Nepomuk@kde.org
https://mail.kde.org/mailman/listinfo/nepomuk
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic