Modularization development notes [was Re: RFA sent to the ArchWG]

Daniel Stone daniel at fooishbar.org
Sun Apr 17 00:51:31 PDT 2005


On Mon, Apr 11, 2005 at 04:57:15PM -0400, Kevin E Martin wrote:
> - Linux (Alpha, AMD64, ARM, IA-32, IA-64, M68k, MIPS, PPC, PPC64,
>   PA-RISC, S/390, Sparc)

Unfortunately I won't be able to test all of these, and Debian is
stupdendously laggard when it comes to X development, so they won't get
to it in time for R7.  I'll be testing on AMD64, i386 (aka IA32), and
PowerPC as definites; IA64, SPARC, and HPPA being probable.

> My initial thought is that we should learn from the past efforts by
> having those involved explain the autotooling process that they used.
> We can then discuss it here on the list, make suggestions and come to
> consensus on how we want to proceed for our project.  By discussing it
> openly, I think that many more developers will be able to become
> involved at an earlier stage since they will understand what is involved
> and how to make it happen.  Also, this discussion will form the basis
> for part of the guide described in the proposal (see documents section
> below for more info).
> 
> What I have in mind here is a simple brain dump of the process used to
> autotool in the xapps, xlibs, xserver and Debrix projects.  I'd also
> like to see us discuss any common conventions that everyone should
> follow so that we have a consistent build system and config options name
> space.
> 
> Other comments/suggestions? [***]

As I've said before, the only really interesting blocker was that of
#includes and how they should appear.  I've had fun times with link
order in debrix, but otherwise it's been fairly straightforward.

Remember to always use make distcheck (if you have files that you need
to distribute that aren't referenced elsewhere useful in Makefile.am,
put them in $(EXTRA_DIST)).  As I go, I've been renaming foo.man to
foo.x (e.g. radeon.man -> radeon.4), so that way you can just use
man_MANS for all your manpages, rather than man_MAN4 or whatever.

I can't think of too much else that's interesting and/or useful,
unfortunately, but obviously if anyone runs into difficulties, I'm sure
that myself and others who have worked on this sort of stuff previously
would be only too happy to help.

> In order for bootstrapping to work, we need to have the capability to
> install and use missing pieces from a monolithic build.  That build may
> be installed in a non-standard place.  For example, I commonly set
> ProjectRoot to be /tmp/Xorg-test.  During the modular development, we
> should make sure that we can set the prefix to install there as well as
> resolve dependencies from that location.

Honestly, I think this will really suck; pkg-config has been a boon, and
attempting to invent our own version sounds like a rather horrid idea.

I'm much happier sticking with our current pkg-config-based approach.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.x.org/archives/xorg-modular/attachments/20050417/a0a5644a/attachment.pgp


More information about the xorg-modular mailing list