libqtmimetypes ?

[Alexander Neundorf]

On Wednesday 16 May 2012, Stephen Kelly wrote:
> Alexander Neundorf wrote:
> >> 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.
> 
> Right, I see.
> 
> > 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.
> 
> Yes, please. I must not have known the difference back when I wrote
> ECMQtFramework.cmake :)

Will do so soon.
 
> >> 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 was misunderstanding where the snippet would go. I thought the tier2
> library would need to know the tier1 LIBRARY_DIR, but I see now I was wrong
> with that.

Actually I'm not sure we should put a LIBRARY_DIR variable at all in the 
Config files. They are needed only in very rare cases, and they may might lead 
people to using link_directories() (which they should not).
 
> >> 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.
> 
> Yury seems to be busy at the moment and hasn't mailed the cmake list yet.
> We might have to plan for him not being able to finish the feature. Maybe
> I can finish it if needed.

That would be great :-)
Also I think this is actually more urgent/important than target_use_target()  
(which of course would be also very cool to have).

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