Sean Champ <sean.p.champ%gmail.com@localhost> writes:
> I'm testing out the builds for my pkgsrc configuration on FreeBSD by
> building wip/emacs-git for an Xaw toolkit with X11_TYPE=native and
> XAW_TYPE=neXtaw. I've defined my X11_BASE=/usr/local/include for the pkgsrc
> builds on FreeBSD.
/usr/local/include is very strange for this.
I actually think I missed something in transcribing my own configuration, there. X11BASE=/usr/local is what I'd been using in effect, albeit obscured in something like the following
~~~~
HOST_LOCALBASE= /usr/local
X11BASE= ${HOST_LOCALBASE}
~~~~
When I was trying to expand the variables for purpose of the email, it seems that I'd added the odd include suffix, lol. So, that was a typo
You could of course build xorg from pkgsrc by using modular. It is
valid to want to use base and I don't mean to discourage you, but am
just pointing that out.
It works out, lol
> I can then set PKGCONFIG_DIR=libdata/pkgconfig in my mk.conf, such that the
> pkgsrc build can find the existing sm.pc file on the host.
Your mk.conf is where your preferences go. If that is where it is in
FreeBSD for everyone, then we should -- somehow -- adjust
platform/FreeBSD.mk to define something so this works for everything
For what it's worth at one point, I'd been testing out some variables by adding those to platform/FreeBSD.mk, at least partly to be sure that those variables would be defined soon enough in the build, though I wasn't certain about that approach. The host ports such that this configuration would make reference to, of course these aren't part of the FreeBSD base system. Maybe the platform/*.mk files could be limited to some invariant features across the essential base system of an opsys?
> After patching each x11 pkg-port for this, then rebuilding and reinstalling
> pkgtools/x11-links it seems to be working out. Perhaps a similar patch
But why are building each x11 package if you are using native?
For purpose of testing my local build with an alternate pkg-config files location, I'd begun by editing
builtin.mk to add the alternate dir for the pkgconfig files. I'd discovered the utility of the BUILTIN_PKGCONFIG_DIRS variable shortly later, lol. Albeit, I'm not sure if it's used under
builtin.mk for x11 pkg builds presently, but perhaps it could be used as so ... assuming that it would have been defined for some local system-variant configuration, at the time when the
buildlink3.mk files are evaluated, lol
For what it's worth, after I'd encountered issues with libiconv and gettext support under pkg builds in the builtin approach, I'd revered to X11_TYPE=modular throughout the pkg builds, then using libiconv and gettext libs from pkgsrc. Maybe the X11_TYPE=native approach is possible. The modular approach might be much more succinct though, lol.
LIBABISUFFIX, as I understand it, is a workaround for the linuxy
practice of putting native libraries in /usr/lib64 (eg. for x86_64) and
emulation libaries (e.g. i386 for a machine that is actually x86_64) in
/usr/lib. NetBSD practice is "don't do that" and I think that's how
FreeBSD is too. Then you shouldn't need that. If you are using that
for some other purpose, that's probably not the right thing to do.
This makes sense