[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: openSUSE packagers' take on the 3 month release cycle
From:       Àlex Fiestas <afiestas () kde ! org>
Date:       2013-07-09 13:39:57
Message-ID: 3422215.I5KVW1VN6m () monsterbad
[Download RAW message or body]

On Tuesday 09 July 2013 13:50:59 Harald Sitter wrote:
> On Tue, Jul 9, 2013 at 12:38 PM, Martin Gräßlin <mgraesslin@kde.org> wrote:
> > On Tuesday 09 July 2013 06:33:21 Scott Kitterman wrote:
> >> On Tuesday, July 09, 2013 12:05:30 PM Àlex Fiestas wrote:
> >> > On Monday 08 July 2013 22:01:29 Andrea Scarpino wrote:
> >> > > We don't just run a sed rule on each spec (pkgbuild, in my case)
> >> > > file.
> >> > > We
> >> > > check for new dependencies (resp. dependencies not needed anymore),
> >> > > new
> >> > > modules (resp. modules not part of the SC anymore), build failure,
> >> > > etc...
> >> > 
> >> > Can't we do something so you don't have to hunt this down but instead
> >> > just
> >> > read a list?
> >> > 
> >> > For build time dependencies, we could do something by looking for
> >> > find_package, and for runtime dependencies we should figure something
> >> > out.
> >> > 
> >> > Our projects are a mess when it comes to runtime dependencies, why
> >> > don't
> >> > we
> >> > fix that for example?
> >> 
> >> How would a run time only dependency be expressed?  I've seen some people
> >> put them in find_package, which is wrong and then we end up having to
> >> patch
> >> it away.
> >> 
> >> For build-time dependencies, particularly determining minimum version
> >> requirements, I end up reading CMakeLists.txt in my favorite editor. 
> >> That's not ideal either.
> > 
> > what about having this information available in a standardized format,
> > e.g. a dependencies.xml?
> 
> json is the new xml, so dependencies.json :P
> 
> while in theory that is a nice idea (just like having a file listing
> all used licenses/copyright holders/whatever) I do not see such a file
> getting maintained reliably. certainly not unless cmake dependency
> tracking/detection is forcefully driven by that file. such that the
> only way to pull dependencies into a kde enabled cmake project is to
> use that file and prevent manual find_package calls, which would
> convenientely make related macros more accessible
> (macro_optional_find_package/macro_log_feature/etc.).
> 
> but since that is rather restrictive and people probably wouldn't like
> it, perhaps the better way to go about this is to enhance cmake. for
> example have a dummy mode where it doesn't generate any files but
> simply catches all find_package calls and lists the thusly detected
> dependencies. that would probably "only' catch some 99% of
> dependencies; on the plus side it does not require someone to maintain
> a list of dependencies manually. of course it doesn't help with
> runtime dependencies but IIRC there was a discussion about how to
> express their requiredness through cmake anyway (such that a user
> compiling from source would know to install it and a distro doesn't
> need to install it for building purposes). if we were to have runtime
> dependencies expressable through cmake as well we could also list
> those in the dependency list so that packagers do not forget to add
> them. with frameworks in particular I suppose we need some approach to
> express which module can be enhanced by another module at runtime...
> 
> I guess what I am saying is, instead of having a separate file to
> track dependencies, why not simply do it in cmake, where we need to
> check for them anyway (cmake could then generate a json file ;)).
> 
> HS

Maybe CMake already has something like this? 
We could add some macro in our 4.X branches but in 5. the trend is to reduce 
the amount of custom macros we depend on, so would be nice if this could end 
in upstream CMake.

Independently of how we do it or whether we do 3 month releases or not, it is 
clear to me that we need something like this in place.
[prev in list] [next in list] [prev in thread] [next in thread]