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>