libqtmimetypes ?

[Alexander Neundorf]

On Sunday 13 May 2012, Stephen Kelly wrote:
> Alexander Neundorf wrote:
> > On Sunday 13 May 2012, Stephen Kelly wrote:
> >> Alexander Neundorf wrote:
> > ...
> > 
> >> > This means either we need to put a lot of work in the buildsystem, to
> >> > handle all cases correctly (and clean up afterwards again), or we
> >> > don't support building standalone for anything tier>1 at all, also
> >> > with Qt5, until either the split has happened or cmake got the new
> >> > feature from Yury.
> >> 
> >> Yes, this is what I would suggest is smartest at the moment.
> > 
> > I thought a bit more about it in the meantime.
> > We can make it work by ignoring the exported targets (and all their nice
> > properties) for the moment and simply do something like the following in
> > the Config files:
> > 
> > find_library(_ at PROJECT_NAME@_LIBRARY NAMES @PROJECT_NAME@
> > 
> >              PATHS ${@PROJECT_NAME at _LIBRARY_DIR}
> >              NO_DEFAULT_PATH)
> > 
> > add_library(@PROJECT_NAME@ IMPORTED)
> > 
> > set_target_properties(@PROJECT_NAME@ PROPERTIES LOCATION ...)
> > 
> > set(@PROJECT_NAME at _LIBRARY ${_ at PROJECT_NAME@_LIBRARY})
> > 
> > It's a pity that it will still not be like it should be, i.e. we still
> > cannot point people to it for a good example (I'd like to get to this
> > state as soon as possible).
> > But it will make it work.
> > Not sure I'll find the time to do it the coming week.
> 
> Why though? Just to get tier2 libraries building standalone? What you
> propose isn't good enough that it gets the tier2 libraries into a final
> state as you say, so why bother? 

It is good enough to make it possible to build them standalone, and have the 
supporting cmake code almost in the final state.
This includes getting correct build dependencies (include dirs) and cmake 
dependencies, where do the files and where do the variables which are used in 
a tier2 library come from.
It will also help to get e-c-m into shape.

> It also looks like it might introduce subtle bugs 

Maybe. But until now we also did quite good in KDE4 without the exported 
targets, so it shouldn't be too bad.

> and be complex to maintain.

Can't be much more complex than it is now ;-)

> For example, why _LIBRARY instead of _LIBRARIES? 

This is what I asked myself when I looked the first at the Config.cmake files 
you create via ECMQtFramework.cmake ;-)
I'll happily change this to plural.

> Someone looking at it will
> think they should use _LIBRARY for their own stuff. If it's _LIBRARY
> because it is a temporary thing, then the _ at PROJECT_NAME@_LIBRARY should
> be used by the caller (with the leading underscore). Also, if this is a
> tier2 config file, then where does ${@PROJECT_NAME at _LIBRARY_DIR} come
> from?

What is the difference in this regard between a tier1 and tier2 library ?
 
> I think it makes more sense to wait until the features are available to
> make it possible to get to our final state (Yury's work). 

If this happens soon, yes.
At least I don't want to wait with this until cmake 2.8.9 has been released.

> Otherwise we'll only get to some transitional state that can't be used for
> anything, or am I wrong?

It will be quite close to the final state, and quite good usable.

Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20120514/c5792113/attachment.html>