[Mesa-dev] [PATCH 4/5] driconf: Add translation-generation to build system, don't track generated files

[Chad Versace]

On 12/04/2012 01:51 PM, Carl Worth wrote:
> Ian Romanick <idr at freedesktop.org> writes:
>> On 12/03/2012 03:43 PM, Carl Worth wrote:
>>> This strangely-escaped apostrophe was causing a build failure
>>> ("invalid escape sequence") resulting in no "de" translations in the
>>> final options.h file.
>>
>> It seems like this patch should go before 4/5 so that bisects will build.
> 
> My phrasing of "build failure" was poor. The build proceeds fine so
> bisect will not be affected, (just some translations will be
> missing). But it's obviously easy to re-order these too. So I'm happy to
> do that.
> 
>> You'll need to get Chad and / or Tapani to help with Android build.
> 
> I'm happy to support Android, so I'm willing to learn whatever is needed
> here.
> 
> That said, I'm not convinced that the current approach we have is
> ideal. The current setup has duplicated information between Makefile.am
> and Android.mk files. This is inherently fragile.
> 
> I would definitely prefer an approach where this is one, canonical build
> system.
> 
> It seems to me, that from Mesa's point-of-view, Android is just another
> distribution. All other distributions are able to use Mesa's build
> system and then package up the results of the build. I think Mesa should
> be happy to host some top-level file to help with that packaging,
> (whether mesa.spec for Fedora, debian/rules for Debian, or Android.mk
> for Android), if the distribution would prefer to have the files in
> Mesa's tree, (some really prefer to maintain this stuff separately).
> 
> But I don't think it makes sense for any distribution to maintain an
> independent build system throughout every level of the Mesa source code.
> 
> Can someone explain what I'm missing? What's the technical justification
> for the current setup?
> 
> -Carl

In this context, it is an error to consider Android as just another Linux
distribution. It's best to consider it an uncanny valley [1] in a foreign
land.

[1] http://en.wikipedia.org/wiki/Uncanny_valley

For starters, one cannot build Android components with Autotools. Redhat's
mesa.spec and Debian's debian/rules simply contain rules on how to
invoke Autotools. On Android, there exists only the One True Android 
Build System [3], which is entirely written in GNU Make. If you'd like a
tour of how the Android build system works, I can walk you through the
basics at the office.

[3] https://android.googlesource.com/platform/build/

A requirement for all Android components is that the build be controlled
by an Android.mk at the project's toplevel. If you're really clever, then
you can write the toplevel Android.mk to invoke an external tool on the build hosts that
scrapes the Makefile.am's and generates the any needed additional Android.mk's.
There is a tool that does this, named Androgenizer [2]. Gstreamer uses it.

[2] http://cgit.collabora.com/git/android/androgenizer.git/tree/README.txt

>From my quick, shallow perusal of the Androgenizer README, it seems
insufficient for Mesa. Mesa's build is complex. For example, Mesa builds
a GLSL compiler executable for the host system (64-bit) that in is in turn used to build a
GLSL library for the target system (32-bit). And there are Python scripts
that transform XML to C. And there's Flex and Bison. And so on. Androgenizer
may be able to accomodate all that, but the README didn't persuade to me
investigate any further.

Imagine a world where no Makefile and no Makefile.am were allowed in Mesa's
source tree. Life would be insufferable. Linux developers would be required
to maintain a parallel fork just for the build system. The build
would constantly break on upstream master. Linux devs would always be hesitant
to rebase their fork onto upstream lest another break.

Taking the Android.mk's out of Mesa without replacing them with an
Androgenizer-like tool would impose that insufferable situation on
the Android developers.