KDE/kdevelop/buildtools/builders/qmakebuilder

Andreas Pakulat apaku at gmx.de
Thu Jul 26 17:09:40 UTC 2007


On 26.07.07 11:48:44, Matt Rogers wrote:
> On Jul 26, 2007, at 4:42 AM, Andreas Pakulat wrote:
> > On 25.07.07 23:24:37, Matt Rogers wrote:
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >>
> >> On Jul 23, 2007, at 6:51 PM, Andreas Pakulat wrote:
> >>
> >>> SVN commit 691596 by apaku:
> >>>
> >>> Allow to easily retrieve the exact binary used in a project. This
> >>> will be used by the QMake Manager.
> >>>
> >>> CC'ing kdevelop-devel to get some input on a question wrt. to this
> >>> change:
> >>> Would it be better to offer something like
> >>> QString queryQMake(const QString& var, KDevelop::IProject*)
> >>> which would basically run qmake -query var and return the result?
> >>>
> >>> I need a way in the qmake manager to run qmake -query var but am
> >>> not 100%
> >>> sure which of the two API's is "better" and I'd like to not
> >>> hardcode the qmake group
> >>> config-key in two places..
> >>>
> >>> CCMAIL:kdevelop-devel at kdevelop.org
> >>
> >> how often are you going to be doing this qmake querying do you think?
> >
> > Once for each project upon opening and the eventually when the user
> > changes the qmake binary setting. So its rather seldom.
> >
> >> The queryQMake function sounds like a nice solution to me.
> >
> > So you think it makes more sense to have this function in the
> > qmake-builder than in the qmake-manager? (Just in case I wasn't clear:
> > The function exists anyway, I'm just not sure where to put it).
> 
> Why would you need it in the qmake builder? I would think that you  
> would only need to query for things in the qmake manager.

I don't, thats why I didn't put it there in the first place and just
provided a small convenience method to fetch the qmake binary (else I'd
have to hardcode the config-options in two places). But you indicated
that a queryQMake function sounds better (or I misunderstood you)...

Andreas

-- 
Give him an evasive answer.




More information about the KDevelop-devel mailing list