[PATCH xserver 0/5] Prepare makefiles for automake 2.0 mandatory subdir-objects

[Matthieu Herrb]

On Tue, Feb 18, 2014 at 06:09:20PM +0100, Mark Kettenis wrote:
> > Date: Mon, 17 Feb 2014 22:26:17 -0500
> > From: Gaetan Nadon <memsize at videotron.ca>
> > 
> > On 14-02-17 05:42 PM, Mark Kettenis wrote:
> > > Ugh, please no.  Can't we just stick to automake 1.x?
> > 
> > We can't stop people from using whatever comes with their distro. With
> > automake 2.0, it will break and will submit patches to fix it.
> 
> Well, given the many incompatible changes, I'm sure distros will
> continue to provide automake 1.x in some form for the foreseeable
> future.
> 
> > > >From a practical point of view, some of us import Xorg into other
> > > version control systems that don't properly support symlinks.
> > 
> > This is interesting.  Does the imported X code include Mesa Graphics
> > Library? It already contains links. Examples:
> > 
> >     ./mesa/mesa/src/gallium/state_trackers/dri/drm/dri_drawable.c
> >     ./mesa/mesa/src/mesa/drivers/dri/r200/radeon_span.c
> 
> Not sure when those links were introduced.  We have Mesa 9.2.5 on
> OpenBSD, but the build process is heavily custumized because the Mesa
> build doesn't fit in with how we build Xorg on OpenBSD.  But I see
> some evidence that these links are one of the reason why we have this
> custom build process.  This makes it a serious effort for us to deal
> with Mesa updates.  Please don't force us to do the same thing for the
> xserver.

Yes, in OpenBSD's copy of Mesa source tree we don't import symbolic
links and deal with VPATH directive in our build system for Mesa.
We had to rewrite a build system for Mesa (and a few others
components) mainly for 2 reasons: 

- the existing upstreams build systems relies too heavily on GNU make
  to be able to patch it locally to be compatible with BSD make.
- there are a number of files that are generated by python
  scripts. Since OpenBSD doesn't have python in the base system, we
  have to include those generated files in the sources we ship, and
  provide for developpers who need to touch the original files a way
  to regenerate the generated files using the ports system's python.

Back to the original topic, I think the X server build process needs
to be fixed to not require symlinks; I've not looked at the exact
problem with automake 2.x yet, but adding symlinks looks like the
wrong answer. (Unless the goal of automake 2.x is to completely piss
off developpers from projects who have not yet switch away from
autotools in order to kill the project).
-- 
Matthieu Herrb