Skip site navigation (1)Skip section navigation (2)
Date:      03 Jul 2002 11:39:48 -0400
From:      Joe Marcus Clarke <marcus@marcuscom.com>
To:        vegacap@i.com.ua
Cc:        gnome@FreeBSD.org
Subject:   Re: bsd.gnomeNG.mk
Message-ID:  <1025710788.319.6.camel@gyros.marcuscom.com>
In-Reply-To: <3D22A9CC.31CE281F@FreeBSD.org>
References:  <3D20736D.9481E0D8@FreeBSD.org> <1025537086.321.4.camel@gyros.marcuscom.com>  <3D21DFC7.15905832@FreeBSD.org> <1025639174.320.78.camel@gyros.marcuscom.com>  <3D22A9CC.31CE281F@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 2002-07-03 at 03:37, Maxim Sobolev wrote:
> Joe Marcus Clarke wrote:
> > 
> > On Tue, 2002-07-02 at 13:15, Maxim Sobolev wrote:
> > > Joe Marcus Clarke wrote:
> > > >
> > > > On Mon, 2002-07-01 at 11:21, Maxim Sobolev wrote:
> > > > > Folks,
> > > > >
> > > > > I really sorry, but my current Real Work and New Possible Work things
> > > > > don't live much time to finish rewrite of bsd.gnome.mk to be more
> > > > > scalable than currently. Paricularly, I've stumbled into the problem
> > > > > with automatic handling of optional dependencies - it seems that it is
> > > > > impossible to correctly implement it in the new framework. Therefore,
> > > > > I am now in favour of dropping that support from bsd.gnomeNG.mk
> > > > > completely and leaving only basic autodetection stuff, so that each
> > > > > particular gnome-optional port will decide what to do with the
> > > > > obtained information (i.e. set LIB/RUN_DEPENDS, PKGNAMESUFFIX and so
> > > > > on). I will try to finish remaining work by tomorrow and submit
> > > > > results for review.
> > > >
> > > > Glad I didn't start on it ;-).  I have some ideas of what I'd like to
> > > > see (something a la the XFREE86_VERSION stuff), but I await your work.
> > >
> > > Ok, see attached, both bsd.gnomeng.mk and example diff for gnomelibs
> > > port. My plan is to make both old bsd.gnome.mk and bsd.gnomeng.mk
> > > co-existing during conversion procedure (say via new USE_GNOMENG knob
> > > for already converted ports) with the goal to burry up old
> > > bsd.gnome.mk completely RSN. The new bsd.gnomeng.mk contains no
> > > provisions for GNOME2 ports, but it could be added later when GNOME1
> > > apps is completely converted to a new framework.
> > >
> > > Any comments or suggestion are as always appreciated.
> > 
> > Well, I'm still picking through it.  It's quite different that what I
> > would have done, but I think it could work.  I _really_ like the
> > consolidated pre-patch expressions :-).  I'm going to have to update the
> > porting guide considerably.
> > 
> > I'm not seeing where you actually look at the value of WANT_GNOME.  You
> > allow a porter to set WANT_GNOME to a list of dependencies, but you
> > treat WANT_GNOME as a boolean macro in bsd.gnomeng.mk (or am I missing
> > something?)  Should the user be able to do the same for WANT_GNOME as
> > they can for USE_GNOME?  I think it would make things more flexible.
> > Also, where do you process HAVE_GNOME?
> 
> I've made WANT_GNOME a boolean variable, which only indicates that
> this particular port instructs bsd.gnomeng.mk to check for actual
> presence of GNOME components on user's system and return a list of all
> actually present components in HAVE_GNOME variable. Initially I've
> played with WANT_GNOME being a list of components, but after thinking
> it out decided that it only makes things more complicated without any
> real benefit. The same applies to WITH_GNOME and WITHOUT_GNOME - now
> they are just boolean variables, indicating that user wants either all
> of GNOME or none of it.

Okay....I was trying to think if having WANT_GNOME as a boolean will
bite us some time down the road.  That is, a port like gaim that sets
WANT_GNOME will then pull in all detectable GNOME components.....I guess
this is okay (as long as WITHOUT_GNOME is respected).

But where do you check HAVE_GNOME?  It looks like you load that variable
up with components, but you don't do anything with it.  You also don't
set USE_GNOME or anything like that (not that you should set
USE_GNOME).  Am I missing something?

> 
> > You add --with-html-dir to the common CONFIGURE_ARGS.  This isn't valid
> > for all GNOME components, though it may not cause a problem.  By that
> > same token, what about adding --disable-gtk-doc to the list?  If it
> > doesn't break anything, it would definitely avoid future problems.
> 
> Done.
> 
> > Also, at line 243, you check to see which components to require if
> > WANT_GNOME is defined.  However, you only check for WITHOUT_GNOME once
> > you enter the for loop.  Wouldn't it be more optimal to check for
> > WITHOUT_GNOME once?  For example, change line 243 to:
> > 
> > .if defined(WANT_GNOME) && !defined(WITHOUT_GNOME)
> > 
> > This way you don't iterate through the for loop at all if the user
> > doesn't want GNOME.
> 
> Noted and fixed, thanks!
> 
> > What ideas do you have for integrating GNOME 2?  Something like creating
> > a _USE_GNOME2_ALL, as well as USE|WANT_GNOME2?  Or would you just add
> > the GNOME 2 bits to _USE_GNOME_ALL, then make the porter choose the
> > right packages for WANT|USE_GNOME?  I like the latter. It might also be
> > nice to have a convention to prevent users from overriding their GNOME
> > desktop of choice (much like a GNOME_VERSION macro in /etc/make.conf).
> > For example:
> > 
> > _GNOME1_DESKTOP=        gnomecore sawfish nautilus ...
> > _GNOME2_DESKTOP=        gnomedesktop gnometerminal gnomesession ...
> > 
> > .if ${GNOME_VERSION} == 2
> > .  for desktopc in ${_GNOME1_DESKTOP}
> > .    for component in ${WANT_GNOME}
> > .      if ${component} == ${desktopc}
> > .        ${ECHO_MSG} This will overwrite your GNOME 2 desktop ...
> > ....
> > 
> > And similar could be done for the GNOME 1 desktop.  I'll let you know if
> > I come up with anything else.
> 
> Well, my plan is to address this on some later date, when all GNOME1
> apps are already converted to bsd.gnomeng.mk. The immediate goal is to
> disconnect all major GNOME1 apps from GNOME1 desktop components, so
> that they could be used with GNOME2 desktop as well. Let's don't mix
> oranges and apples. ;)

I understand.  My point was simply to look ahead so as not to paint
ourselves into a corner.  I wanted to make sure the NG framework will
scale to an acceptable solution for GNOME 2.  I think there is some room
there based on my above idea (you may have others), and that's what I
was trying to put forward.

> 
> If you don't object, I would like to commit bsd.gnomeng.mk today,
> introduce USE_GNOMENG knob into bsd.gnome.mk and start converting
> GNOME1 core components and application after that.

I don't mind if you address my HAVE_GNOME question above.  Thanks, and
good work!

Joe

> 
> -Maxim
> 
-- 
PGP Key : http://www.marcuscom.com/pgp.asc

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-gnome" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1025710788.319.6.camel>