jbb at kdevelop.org
Fri Jun 7 23:49:02 UTC 2002
On Tue, 04 Jun 2002 03:11, Simon Hausmann wrote:
> On Mon, Jun 03, 2002 at 03:58:39PM +0200, Bernd Gehrmann wrote:
> > On Monday 03 June 2002 02:24, you wrote:
> > > Hi,
> > >
> > > Here's a small patch that attempts to find the subdirs associated with
> > > variables within a Makefile.am eg
> > > SUBDIRS = blah1 blah2 $(BLAH_DIRS) blah3
> > Have you heard about QMap::find()? ;-)
I have now :-))
> > > I have no solution for this. Anybody with thoughts on how this could be
> > > handled? Perhaps the vars should just remain in the Automake Manager
> > > view if not found and then the dirs could be added manually (this would
> > > be a bad hack though).
> > My idea was to allow pseudo-comments to be added to the Makefile.am,
> > e.g.
> > #kdevelop-substitute BLA_DIRS = foobar
> > Then the parser would treat such variable assignment like normal ones,
> > whereas automake/unsermake would simply skip such lines.
> > Of course, this would have to be documented somewhere...
> With unsermake approaching fast, the old-style of doing AC_SUBST in
> configure.in.in for BLAH_DIRS is becoming obsolete in the KDE CVS
> repository anyway. The new approach uses automake conditionals,
> which perfectly match with John's first approach:
> if include_foobar
But I can imagine this being done...
How should that be resolved?
I'm beginning to think that the variables should be added to the "Automake
Manager". If the dirs can be resolved then they should be added underneath
the variable. Otherwise they'll need to be added manually by the user.
On import we need to get the user to resolve these variables somehow or at
least indicate that they'll need to do this.
Adding dirs underneath a variable that cannot be resolved by looking into the
Makefile.am shouldn't alter the Makefile.am but adding dirs to one that can
be resolved should.
Currently importing kdevelop3 loses it's view into the src and kdevelop
directory which makes it harder to work on the project.
I have no code to show and the idea feels hackish :-( Any thoughts...
More information about the KDevelop-devel