[Pixman] [PATCH] configure: add options to disable demos and tests

[Oded Gabbay]

On Sun, Jan 31, 2016 at 4:11 PM, Oded Gabbay <oded.gabbay at gmail.com> wrote:
> On Wed, Jan 20, 2016 at 8:35 PM, Bill Spitzak <spitzak at gmail.com> wrote:
>> The ability to disabling everything except the library itself seems like a
>> good idea.
>>
>> Make sure "make test" fails if tests are disabled.
>>
>> I do think it would be nice to actually patch the tests so they compile on
>> these platforms.
>>
>> On Wed, Jan 20, 2016 at 1:13 AM, Thomas Petazzoni
>> <thomas.petazzoni at free-electrons.com> wrote:
>>>
>>> Hello,
>>>
>>> On Wed, 20 Jan 2016 09:27:46 +0200, Siarhei Siamashka wrote:
>>>
>>> > Thanks for this patch. Though if building (and using) pixman on
>>> > such platforms is wanted, then a much better solution would be to
>>> > update the problematic tests and make them compile. Skipping some
>>> > sub-tests is better than having no tests at all. I also remember
>>> > your patch for FE_DIVBYZERO from a few months ago:
>>> >
>>> >
>>> > http://lists.freedesktop.org/archives/pixman/2015-September/004019.html
>>> >
>>> > Is it still the same Microblaze or Nios2 architecture that is causing
>>> > problems for you?
>>>
>>> Yes, it is. Other architectures might be affected because the <fenv.h>
>>> implementation in uClibc is not complete for all architectures.
>>>
>>> > While adding new configure options just adds functionality and
>>> > preserves the existing behavior, I don't feel very happy about
>>> > the fact that this provides an easy way to ignore problems instead
>>> > of fixing them. It would be really great is somebody tried to run
>>> > the pixman test suite ("make check") on these architectures at
>>> > least once.
>>> >
>>> > Encountering compiler bugs is unfortunately a regular occurrence
>>> > for pixman. For example, not so long ago, GCC 4.9 miscompiled
>>> > pixman on ARM (fortunately, the broken code was in the test suite
>>> > itself and not in the pixman library):
>>> >
>>> >     https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64172
>>> >
>>> > And even just a few days ago, pixman was one of the victims during
>>> > a GCC 6 snapshot test (an easy to notice ICE during a distro test
>>> > rebuild):
>>> >
>>> >     https://gcc.gnu.org/ml/gcc/2016-01/msg00101.html
>>> >     https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66856
>>> >
>>> > What I'm trying to say is that there had been many compiler bugs
>>> > affecting pixman during the last few years. Now you are dealing
>>> > with uncommon architectures, and the compilers there are probably
>>> > even less mature than GCC on x86 / arm / powerpc.
>>>
>>> I agree, but those options also allow to skip building things that
>>> won't be used, even if they actually build properly. On ARM, x86,
>>> PowerPC and other "mainstream" architectures, the demos and tests build
>>> fine, but they are not used at all by Buildroot, so it's just spending
>>> time building things that aren't necessary.
>>>
>>> So even if those tests and demos were building for all architectures,
>>> it would still be useful to have a way to *not* build them.
>>>
>>> But I'll have a look at re-enabling the building of the pixman tests in
>>> Buildroot. Now that the FE_* things are disabled in the tests when not
>>> available (after commit 4297e9058d252cac653723fe0b1bee559fbac3a4).
>>>
>>> Thanks!
>>>
>>> Thomas
>>> --
>>> Thomas Petazzoni, CTO, Free Electrons
>>> Embedded Linux, Kernel and Android engineering
>>> http://free-electrons.com
>>> _______________________________________________
>>> Pixman mailing list
>>> Pixman at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/pixman
>>
>>
>>
>> _______________________________________________
>> Pixman mailing list
>> Pixman at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/pixman
>>
>
>
> Siarhei,
>
> I agree with you in principal, but the reality is different.
> When I worked on embedded devices and cross-compiling rpm packages, I
> often had hard times with packages that didn't allow to disable the
> tests. That is because you don't want the package building process to
> run the tests on the host machine, as it will fail because the library
> is built for target machine. In addition, sometimes you wanted to
> minimize the size of the library to minimum due to space constraints,
> and tests/demos are the first candidate for that.
>
> So for libraries that gave the option to disable the tests, the
> solution was easy. For other libraries I had to patch the configure
> script / makefiles and curse the library developers ;)
>
> Therefore, I believe there is a real justification for this. Although
> it can be "abused" for skipping the tests, there are real world
> use-cases for it.
>
> Oded

Hi Siarhei,
I didn't get any reply from you on this (Agree/disagree/partially agree/etc).
Any strong objection to merge this ?

Thanks,

     Oded