ports/115870: [DEPS] graphics/cairo reduce X dependencies

[Jeremy Messenger]

On Tue, 04 Sep 2007 09:46:07 -0500, Alexander Leidinger  
<Alexander at Leidinger.net> wrote:

> Quoting Pav Lucistnik <pav at FreeBSD.org> (Tue, 04 Sep 2007 15:47:59  
> +0200):
>
>> Alexander Leidinger píše v út 04. 09. 2007 v 15:38 +0200:
>>
>> > Increasing the number from e.g. 3 to e.g. 20 does not slow down that
>>
>> No, only tenfold.
>
> On paper, but what matters is if the the wall clock time changes
> significantly or not. As said, without numbers there's no reason to
> discuss this now.
>
>> > > You are operating on false assumptions here. Let me explain how  
>> libtool
>> > > on FreeBSD work. It explicitly passes all indirectly required  
>> libraries
>> > > to the linker during build. So they all get recorded in the shared
>> >
>> > AFAIK it operated like this in the past, but not now anymore (it was
>> > one of the complains des(?) had with the autotools ports, it is not
>> > present in the old libtool versions, but AFAIK it is present in a
>> > recent libtool version). I will check this to make sure it works and
>> > come back to you with the result.
>>
>> Go check; I believe it still does this.
>>
>> > BTW: I just checked for gtk20 after my last mail. They have .pc files
>> > for the installed and uninstalled case. The uninstalled case lists
>> > the .la file in the build directory together with all dependencies.  
>> The
>> > installed case lists the compiler flags together with all  
>> dependencies.
>> > I'm in the process of testing the removal of the dependencies from
>> > the .pc file for the installed case.
>>
>> I seriously doubt gtk20 port maintainers will accept FreeBSD specific
>> hackery on installed .pc files.
>
> You mean more hackery (one reinplace command) than already existing (I
> don't count the reinplace things in USE_GNOME=gnomehack now)?

Half of that gnomehack stuff are gone in GNOME 2.20. As for the others  
such as libdata and share/locale, we are following the hier(7), that's it.  
Right now, the gnomehack for GNOME 2.20 looks like:

==========================================
gnomehack_PRE_PATCH=	${FIND} ${WRKSRC} -name "${GNOME_MAKEFILEIN}*" -type  
f | ${XARGS} ${REINPLACE_CMD} -e \
				's|[(]libdir[)]/locale|(prefix)/share/locale|g ; \
				 s|[(]libdir[)]/pkgconfig|(prefix)/libdata/pkgconfig|g ; \
				 s|[(]datadir[)]/pkgconfig|(prefix)/libdata/pkgconfig|g ; \
				 s|[$$][(]localstatedir[)]/scrollkeeper|${SCROLLKEEPER_DIR}|g ; \
				 s|[(]libdir[)]/bonobo/servers|(prefix)/libdata/bonobo/servers|g' ; \
			${FIND} ${WRKSRC} -name "configure" -type f | ${XARGS} ${REINPLACE_CMD}  
-e \
				's|-lpthread|${PTHREAD_LIBS}|g ; \
				 s|DATADIRNAME=lib|DATADIRNAME=share|g ; \
				 s|{libdir}/locale|{prefix}/share/locale|g'
==========================================

We are moving all stuff from share/gnome/ to share/. It's a big change.

Cheers,
Mezz

> Apart from this, I'm looking for a more generic solution (which would
> be beneficial to other OS which recursively resolve libs too).
>
>> > And regarding the "better be safe than broken" part... we all know
>> > about the mails after a KDE/GNOME/X11/... update. So far there where
>> > bugreports all the time after a major upgrade. Some problems are
>> > because of missing dependencies, some are because of missed
>> > portrevision bumps. By listing the explicit depends you get rid of  
>> some
>> > complains (no missed libs, ability to check for more affected ports
>> > than now). And by adding a check-script to pointyhat runs, you can  
>> even
>> > get the big picture and are not limited to your local testing.
>>
>> I'd like to split the debate into two parts
>>
>> 1) dependency validation script, a tool for maintainers, portlint style
>>
>> A good thing, no question.
>>
>> 2) recording all indirect dependencies explicitly in ports
>>
>> A bad thing, a total no go.
>
> There seems to be a misunderstanding on your side. Sorry if I failed to
> tell you about my intentions in a clear way. I agree totally with you
> here. I don't want to record implicit dependencies explicitly in ports.
> Only those with direct symbol references in the binaries. If there's no
> direct reference to symbols defined in libpng, there should be no
> reference to libpng in the binary of a port. That's the reason why I
> look into the .pc files now (removing superfluous dependencies in a
> portable way so it can go into the official tarballs).
>
> Don't be scared, this is nothing which will go into the tree "soon". I
> expect that I have to fix several bugs before I can offer a patch with
> the explicit dependencies for testing. And after the patch is
> available, it will take some time until is in a state where we can have
> a look at statistics and discussing it in detail. Please don't judge
> before you've seen the complete implementation, I'm at the beginning of
> the work and there will be several changes needed.
>
> Bye,
> Alexander.
>



-- 
mezz7 at cox.net  -  mezz at FreeBSD.org
FreeBSD GNOME Team  -  FreeBSD Multimedia Hat (ports, not src)
http://www.FreeBSD.org/gnome/  -  gnome at FreeBSD.org
http://wiki.freebsd.org/multimedia  -  multimedia at FreeBSD.org