[oi-dev] Deduplicating illumos-userland

[Alasdair Lumsden]

Hi All,

In s10-userland, early on we abstracted a lot of commonly used macros up into the shared-macros area. Unfortunately illumos-userland doesn't have this and it has created a situation where a lot of Makefiles unnecessarily duplicate macros.

For example, in s10-userland we added the following to configure.mk

CONFIGURE_ENV   +=      CC="$(CC)"
CONFIGURE_ENV   +=      CXX="$(CXX)"
CONFIGURE_ENV   +=      CFLAGS="$(CFLAGS)"
CONFIGURE_ENV   +=      LDFLAGS="$(LDFLAGS)"
CONFIGURE_ENV	+=      PKG_CONFIG="$(PKG_CONFIG_PATH)"

# Tell autoconf about 64bit builds
CONFIGURE_OPTIONS.64 += --build=x86_64-pc-solaris$(SOLARIS_VERSION)

CONFIGURE_LOCALSTATEDIR =       $(CONFIGURE_PREFIX)/var
CONFIGURE_OPTIONS += --infodir=$(CONFIGURE_INFODIR)
CONFIGURE_OPTIONS += --sysconfdir=$(CONFIGURE_SYSCONFDIR)
CONFIGURE_OPTIONS += --localstatedir=$(CONFIGURE_LOCALSTATEDIR)

In shared-macros.mk we added:

LDFLAGS+=	$(LD_BITS)

(Note that the --build above needs improving for SPARC, can probably be derived from MACH64 somehow)

The above is all completely missing from illumos-userland/userland-gate for no apparent reason. In s10-userland, we found adding this stuff this flushed out a lot packaging mistakes. For example a lot of software leverages pkgconfig, and 64bit builds were using 32bit pkgconfig cflags/ldflags. Also autoconf/libtool use --build to determine various things related to bittiness; setting -m64 is not by itself always enough.

We found few cases where the above caused issues (I can't think of any off the top of my head). There are occasions when a software component has a configure script that is not generated by autoconf, that barfs on some of the above flags, but the correct way to deal with that is set CONFIGURE_OPTIONS= instead of += and define the precise arguments it takes, since these non-autoconf configure scripts are rare and always bespoke.

Ideally we want to cater for the general common cases first, avoid unnecessary duplication, and err on the side of safety (which --build and PKG_CONFIG for 64bit improves). Here is random example of how this will cut down on duplicated cruft:

--- gd2/Makefile        2012-05-05 14:31:12.052620402 +0100
+++ /tmp/gd2_Makefile_new       2012-05-05 16:58:11.668117871 +0100
@@ -37,18 +37,11 @@
 include ../../make-rules/ips.mk
 include ../../make-rules/lint-libraries.mk
 
-PKG_CONFIG_PATH_32 = /usr/lib/pkgconfig
-PKG_CONFIG_PATH_64 = /usr/lib/$(MACH64)/pkgconfig
-
 PATCH_LEVEL = 0
 
 CFLAGS += $(CPP_LARGEFILES)
 CPPFLAGS += $(CPP_LARGEFILES)
 
-CONFIGURE_ENV += CFLAGS="$(CFLAGS)"
-CONFIGURE_ENV += CPPFLAGS="$(CPPFLAGS)"
-CONFIGURE_ENV += PKG_CONFIG_PATH="$(PKG_CONFIG_PATH_$(BITS))"
-
 CONFIGURE_OPTIONS  +=           --includedir=$(CONFIGURE_INCLUDEDIR)/gd2
 CONFIGURE_OPTIONS  +=           --disable-static
 CONFIGURE_OPTIONS  +=           --disable-rpath


We also created a new make-rules/gnu-ld.mk file that could be included to get GNU ld (unfortunately needed for some multimedia software that uses linker features the Sun linker doesn't support). One for OI would contain:

COMPONENT_BUILD_ENV+=	LD_ALTEXEC=/usr/gnu/bin/ld
COMPONENT_INSTALL_ENV+=	LD_ALTEXEC=/usr/gnu/bin/ld
CONFIGURE_ENV+=		LD=$(ECPREFIX)/bin/ld
CONFIGURE_OPTIONS+=	--with-gnu-ld

(Note on s10-userland we actually supply a 32bit and 64bit build of gnu-binutils as we found a 64bit gld was necessary to link some 64bit objects - I forget the details but this is something that we can look at down the road when we start packaging that software up).

We could also add a make-rules/ncurses.mk:

# Use ncurses
CURSES_DIR_32=  /usr/gnu/lib
CURSES_DIR_64=  /usr/gnu/lib/$(MACH64)
CURSES_DIR=     $(CURSES_DIR_$(BITS))
LDFLAGS+=       -L$(CURSES_DIR) -R$(CURSES_DIR)
CPPFLAGS+=      -I/usr/include/ncurses

This ncurses definition block is used in a number of components that require ncurses, so it makes sense to abstract it out.

The gnu-ld.mk/ncurses.mk files are used by simply adding an "include ../make-rules/[blah].mk" line to the component Makefile.

Before I file some issues and begin work on some changesets, does anyone have any feedback/comments?

Cheers,

Alasdair