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>