[karchive] /: Show how qmake integration can be done.

[Alexander Neundorf]

On Sunday 05 January 2014, Alexander Neundorf wrote:
> On Sunday 05 January 2014, you wrote:
> > On Sunday 05 January 2014 18:59:58 Alexander Neundorf wrote:
> > > On Sunday 05 January 2014, you wrote:
> > > > On Sunday 05 January 2014 18:41:18 Alexander Neundorf wrote:
> > > > > On Saturday 04 January 2014, you wrote:
> > > > > > On Saturday 04 January 2014 22:25:36 David Faure wrote:
> > > > > > > On Saturday 04 January 2014 22:19:29 Alexander Neundorf wrote:
> > > > > > > > >  ecm_generate_pri_file(KF5KIOCore BASE_NAME KIOCore
> > > > > > > > >  VARIABLE_PREFIX KIO
> > > > > > > > > 
> > > > > > > > > DEPS "KCoreAddons KService")
> > > > > > > > 
> > > > > > > > I think so.
> > > > > > > > I'd be even more explicit and add something like "FILE
> > > > > > > > KF5KIOCore.pri",
> > > > > > > > then  it's clear to the reader what is generated ("FILE" is
> > > > > > > > already
> > > > > > > > used this way in install(EXPORT ... ) ).
> > > > > > > 
> > > > > > > The first argument is the target name (so I didn't prefix it,
> > > > > > > which is consistent with most other commands that take a target
> > > > > > > name first).
> > > > > > > 
> > > > > > > It's not used for the filename (that's qt_KIOCore.pri, i.e. it
> > > > > > > comes from
> > > > > > > BASE_NAME) but to write out the name of the library into the
> > > > > > > file.
> > > > > 
> > > > > Ah.
> > > > > Is BASE_NAME also used for something else, or just that ?
> > > > 
> > > > It's also used as the name of the thing to include, i.e. QT +=
> > > > KIOCore.
> > > > 
> > > > > I'd make it "FILENAME ${MaybeSomeDir}/qt_KIOCore.pri" then, and
> > > > > error out
> > > > > if the given filename doesn't match "qt_.+\.pri/" or something like
> > > > > that. This is done the same way for the FOUND_VAR argument in
> > > > > find_package_handle_standard_args().
> > > > > It's a bit more typing, but it's easy to read and with such a check
> > > > > hard to get wrong.
> > > > 
> > > > I think the filename is actually an implementation detail.
> > > 
> > > Well, later on the generated filename must be used in an install(FILES
> > > ...) call, right ?
> > > IMO it's nice to see where that filename used there comes from.
> > 
> > Oh! You're right. OK then I'll do that.
> > 
> > The alternative would be the set the filename in some "output variable",
> > to hide this detail in the implementation of the function. Wouldn't that
> > be better?
> 
> That's also ok.
> 
> > > > Any comments on my framework_version.diff patch from earlier today?
> > > 
> > > What was the subject ?
> > 
> > Same thread as this one, same subject. Today 11:09 CET.
> 
> I'll have a look.

(...without looking at the replies) I wouldn't do that, IMO too much "magic" 
going on.
Why should a function called ecm_setup_version() set variables called 
FRAMEWORK_SOMETHING ?
"framework" as used in this context means framework as used here in KDE.
ecm_setup_version() is not KDE specific.
I would probably expect it to mean framework as found on OSX.

I'd just hand the version number as argument to ecm_generate_pri_file() and 
then it's easy to read and no magic or confusion involved (...but more 
typing).

Alex