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

[Gaetan Nadon]

On 14-02-18 12:24 PM, Matthieu Herrb wrote:
> 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.
Yes, for a while. But it means users will have to go out their way to
replace it. Patches will be submitted, in all shapes and forms, over and
over again.
>>
>>>> >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;
There are no symlinks in git  in any of the 250 X modules.
>  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).

This is great feedback. So links are not the ideal solution, in fact, no
solution at all for many.

To my knowledge, this leaves us with the ideal solution I call "code
re-factoring" to replace the cherry-picking of reusable source files
which is exemplified by Jon Turney 's patch earlier in this thread.

I've CC Emil Velikov for Mesa who has a bug report for the same issue.

I am withdrawing this patch series and turning the problem over to the X
server developers. There are 18 makefiles that are broken under automake
2.0 (warnings under 1.14).