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

[David Faure]

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. If one day qmake is 
improved to not require everything to be qt_* and QT.* and QT +=, then
we might want to call the generated files kf5_* or kf_* or something.
All very hypothetical at this point, but this is a possible vector of change 
which makes me want to leave the actual filename as an implementation detail.

The goal is to "install what's needed to QT += KIOCore", the actual filename 
is just a result of internal qmake mechanics.

> > ... should I add LIBRARY in front of the first argument, or leave it like
> > this?
> 
> In doubt, add the keyword. Sometimes it hurts later on when there is none
> (...because it can make the function harder to modify/extend).

OK, thanks.

Any comments on my framework_version.diff patch from earlier today?

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5