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

[Emil Velikov]

Hello gents,

Pardon all the intrusion, especially as I'm somewhat of an outsider when
it comes to X.

On 19/02/14 17:45, Gaetan Nadon wrote:
> 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.
Seconded, patches will come again and again until the problem is
resolved. One should take a look and fix it, rather than expecting
distros(users) to use automake 1.x till the end of time.

>>>
>>>>> >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.
>>
I feel sorry for you guys. AFAICS mesa's build is more complex than that
of X due to the vast amount of build options and all their permutations.
If you guys feel like it can be improved let us know, rather than
working around the problem.

>> 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).
> 
> 
IMHO justifying code re-factoring and/or build system re-write due to
"my cvs does not support symlinks" is just plain silly.

In my naive POV one should take a look into add support for such a
fundamental feature in a way that is handled correctly across platforms
that do not even support symlinks. AFAIK autoconf/automake handles that
so other projects should be capable to do the same.

Even if everyone is keen on rewriting X(or X's build system) there will
be another project that would still depend on symlink support.

Note: that does not justify that one creates XXX symlinks just to
silence automake up. I've been going through mesa cleaning up and using
symlinks(once or twice so far) only to prevent stupendous amount of code
duplication.

-Emil