Date: Thu, 09 Mar 2017 10:20:48 -0800 From: John Baldwin <jhb@freebsd.org> To: freebsd-arch@freebsd.org Cc: Dag-Erling =?ISO-8859-1?Q?Sm=F8rgrav?= <des@des.no>, Baptiste Daroussin <bapt@freebsd.org>, ports@freebsd.org, arch@freebsd.org Subject: Re: manpath change for ports ? Message-ID: <2721378.xr7MGKcqvA@ralph.baldwin.cx> In-Reply-To: <86mvcvojzt.fsf@desk.des.no> References: <20170306235610.cmpxk27jhoafel6l@ivaldir.net> <86mvcvojzt.fsf@desk.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday, March 08, 2017 04:39:50 PM Dag-Erling Sm=F8rgrav wrote: > Baptiste Daroussin <bapt@FreeBSD.org> writes: > > I would like to propose a change in the localbase hier for ports > > > > I think we should add /usr/local/share/man in the manpath along wit= h > > at first and maybe instead of in long term. >=20 > 2) plus info -> share/info as suggested by jbeich >=20 > 3) plus libdata/pkgconfig -> lib/pkgconfig >=20 > These three items will ensure that "./configure --prefix=3D/usr/local= && > make install" will do the right thing out of the box - by changing ou= r > definition of "the right thing" to match what the GNU autotools have > been doing for at least 15 years. >=20 > 4) Remove the hardcoded library path in lang/gcc* >=20 > This makes it possible to work on software that includes both librari= es > and programs while an earlier copy of the same software is already > installed. With the current state of gcc, the programs you are worki= ng > on will be linked against the version of the library that's already > installed instead of the version you just compiled, and there is noth= ing > you can do to prevent it. You won't notice anything if all you ever = do > is "make && make install", because the new library will replace the o= ld, > but if you try to run your program directly from the build tree, it w= ill > use the wrong library. This can be incredibly frustrating if you're = not > aware of it - imagine you're trying to fix a bug in that library and = no > matter what you do, your regression test keeps failing... +1 on all these. I think that ports compilers should not have /usr/local/include or /usr/local/lib as implicit paths either as others= have stated. I wouldn't even mind if we had both /usr/local/man and /usr/local/share= /man so long as our default MANPATH included both if that means applying few= er patches to ports. --=20 John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2721378.xr7MGKcqvA>