openSUSE packagers' take on the 3 month release cycle

[Alexander Neundorf]

On Tuesday 09 July 2013, Àlex Fiestas wrote:
> On Tuesday 09 July 2013 13:50:59 Harald Sitter wrote:
> > On Tue, Jul 9, 2013 at 12:38 PM, Martin Gräßlin <mgraesslin at 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.

It is, at least kind of:
feature_summary(WHAT ALL
                FILENAME ${CMAKE_BINARY_DIR}/deps.log)

This does not track find_package() calls which have not been executed, due to 
whatever reasons.

Alex