[Mesa-dev] [PATCH 4/4] autoconf, scons: Move fallback HAVE_* definitions to headers.

[Emil Velikov]

On 7 April 2015 at 16:21, Jose Fonseca <jfonseca at vmware.com> wrote:
> On 07/04/15 15:01, Emil Velikov wrote:
...
>>
>> So let see if I got this correct, apologies in advance if it comes out
>> too blunt.
>>
>> Unless I'm mistaken the gallium interfaces are internal/private, so
>> comparing them with public ones (like the Khronos OpenGL) seems like
>> comparing apples to oranges. Yet as one tries to have/use gallium
>> interfaces as if they were public, the idea of gettting some of this
>> #ifdef-ery into a single, isolated and easily manageable place is
>> valid and honourable.
>
>
> From my POV, Gallium interfaces are public and always have been. Admittedly,
> there's no standards body, and the interface is neither stable nor does it
> provide backwards compatibility.  But pretty much from as far as I can
> remember (which is 2007) there were external (as in out-of-tree)
> state-trackers and even externals drivers.
>
Don't mean to be cheeky but do you have an example of a project that
has a public interface that is neither stable nor backwards compatible
? Don't think I've heard about one, so I must admit that I found your
statement rather surprising. Then again I have been proven narrow
minded on a occasion or two.

>
> BTW, another solution would be for autotools to generate a "config.h".
>
> And have SCons, etc, include a hand-written drop-in config.h (living in a
> separate directory.)
>
> This is actually a practice that many projects (out of my head I can name
> zlib, linpng, tiff, etc) do.
>
I had the same idea for a few months now. Although that would likely
be a slow and long transition, as I would like to avoid severe
breakages.


> Another alternative is for me to pre-include this fakeconfig.h , ie., `gcc
> --include fakeconfig.h`, MSVC's `/Fifakeconfig.h`
>
Imho this sounds like a the better solution. This way when someone
uses gallium interfaces as public they can include it explicitly.


>
>> Afaict the overhead of rebasing an integrated solution on top of newer
>> mesa, would be less than having it out-of-tree. Plus it seems like the
>> better engineering approach. Perhaps I'm missing something and this
>> does not hold true ?
>
>
> I'm afraid it doesn't hold true.  It's not worth going into specifics, but
> imagine the following: there's Mesa, theres our Product, and there's the
> Component linking both.  Mesa has its build system. The Product has its
> build system.  Both Product and Mesa are huge, so building one inside the
> other it's just impractical.  What you can do is choose to build the
> Component inside Mesa or inside the Product, but either way you'll end up
> the variations of the same problem.  Which is one is easier depends on how
> tightly the Component is integrated with Mesa vs the Product.
>
> The component is sort of a Direct3D state tracker, and is way more tightly
> integrated into the rest of the Product than Mesa, as it really one needs
> the gallium headers and a few of the helper modules.
>
The situation sounds familiar, although I might be bit biased on the
topic. Let me reword your sentence with an example in place:

You have a Component (st/omx) , which depends on Product
(omx-bellagio) at compile/link time. Does your platform(s) has tools
similar to pkg-config & cmake's package-config ?

If so one should be able to tackle it as follows:
 1. Bring some versioning into Product.
 2. Making sure that Product's headers/libraries are available via the
pkg-config(alike) tool.
 3. Add the check for Product into the autotools/scons build
 4. Integrate(merge) Component into Mesa.

It does have one small catch though
 - Product cannot on depend on Mesa at link time. One can get around
this but it requires some non-trivial changes.

Suspecting that the situation might be more elaborate than presented
(or I did not fully understood it) and I'm not trying to push you to
disclose any more information. Just saying that as presented it does
not sound so complex.


Thanks for the comprehensive explanation.

Cheers,
Emil