Date: Wed, 03 Jul 2002 10:37:48 +0300 From: Maxim Sobolev <sobomax@FreeBSD.org> To: Joe Marcus Clarke <marcus@marcuscom.com> Cc: gnome@FreeBSD.org Subject: Re: bsd.gnomeNG.mk Message-ID: <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>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
> 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. ;)
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.
-Maxim
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?3D22A9CC.31CE281F>