[vlc-devel] [vlc-commits] configure: unbreak cross-pkg-config support with contrib

[Rafaël Carré]

On 03/04/14 08:50, Rémi Denis-Courmont wrote:
> On Mon, 03 Mar 2014 21:00:23 +0100, Rafaël Carré <funman at videolan.org>
> wrote:
>> Where's
>>
>> On 03/03/14 15:23, Rémi Denis-Courmont wrote:
>>> On Mon, 03 Mar 2014 15:07:16 +0100, Rémi Denis-Courmont
>>> <remi at remlab.net>
>>> wrote:
>>>>> What is 'cross-pkg-config tools' exactly ?
>>>>
>>>> $(CROSS)-pkg-config.
>>>>
>>>>> I only saw something like this in Fedora and I have no idea yet how
>>>>> hacky it is.
>>>>
>>>> Debian does it too and I believe it is part of pkg-config.
>>>
>>> Indeed, that actually comes from upstream pkg-config, not from Debian
>>> mingw64-tools. The automake macro calls AC_CHECK_TOOL expecting a
>>> $(host)-specific cross-tool (as opposed to AC_CHECK_PROG) just like the
>>> compiler and the linker. So this commit is just matching the expected
>>> pkg-config usage.
>>
>> We can make sure we're always using 'pkg-config' instead of a
>> distro-specific
>> $(CROSS)-pkg-config.
> 
> Essentially, this amounts to breaking correctly configured SDKs to
> optimize for unconfigured ones. I don't know if it works. But that seems
> rather cumbersone, as compared to configuring the unconfigured SDKs.

http://pkgconfig.freedesktop.org/releases/

No trace of prefixed-pkg-config here.

I doubt "Correctly configured" means "with some unspecified
distro-specific script".

> Unincidentally, this is basically what contrib already does. It does set
> the pkg-config environment correctly for cross-compilation targets that
> lack those environment variables, globally - not in the per-package
> configure script or Makefile or whatever.
> 
>> If you want to use distibution provided cross libraries (I am not sure
>> if that is a good idea anyway) you can always use export
>> PKG_CONFIG_PATH=/distro/prefix
> 
> For the fifth or sixth time now, the pkg-config automake macro favors the
> cross-prefix pkg-config over the native one. Sure, I find it convenient.
> But this is NOT my decision any more than it was my decision to derecursify
> the build system last summer. This is how autotools work. If you want to
> use something else than autotools, you are more than welcome to propose a
> better alternative. I do not have time for that.
> 
>>> Generally speaking, it is not the job of the contrib snippet of the VLC
>>> configure script to guess whether the pkg-config environment is right
> or
>>> wrong, anymore than that of other build tools. That is the job of the
>>> caller (of the script) or of the SDK. The --with-contrib option is
> meant
>>> to *add* contribs to the search path.
>>
>> Your goal toward perfection and guessing whose job is what might be
>> commendable.
>>
>> However as you were told before I will not let you break other people
>> setup doing so.
> 
> While it is arguably laudable to protect people from build breakages, this
> is self-defeating purpose.
> Reverting this patch and reintroducing the kludgy correlation between
> using VLC contribs and cross-compiling on the one hand, and overriding the
> pkg-config library path on the other hand, does break the Win32
> configuration of anyone with a system like mine.
> 
>> That patch is at best incomplete if not completely incorrect (for
>> handling a distro specific script)
> 
> pkg.m4 is not a distribution-specific script. It calls AC_CHECK_TOOLS, not
> AC_CHECK_PROGS.
> 
>> and in any case should have been posted here before.
> 
> You say that and you proclaim yourself the Windows maintainer. The reality
> with the Win32 port however is that:
> 
> - Packaging has been (accidentally) broken for over a year by Felix with
> NPAPI. He acknowledged but reported his inability to fix it. The bug has
> been reported for quite a while.

Again you are avoiding the details such as bug number for this
hypothetical problem.

> - Packaging depends on a hard-coded path to WINE for the ActiveX. That
> breaks any system who WINE path does not match that of the Makefile author
> (including any recent Linux distro), and prevents builds from non-x86.

You can always set WINE_SDK_PATH.

> - Without this patch, configure will not even complete with mingw64-tools.

mingw-w64-tools does not and will not provide pkg-config.

% ls -l `which i686-w64-mingw32-pkg-config`
lrwxrwxrwx 1 root root 32 janv. 10 07:19
/usr/bin/i686-w64-mingw32-pkg-config -> ../share/pkg-config-crosswrapper
% dpkg -S /usr/share/pkg-config-crosswrapper
pkg-config: /usr/share/pkg-config-crosswrapper

So thanks for optimizing for some custom distro without even checking
your facts.

> - With recent Mingw64, you have to hack and remove files from the SDK to
> avoid linking against pthread (not much the spirit of the GPL).

Thanks for showing you don't know anything about mingw-w64 either.

*gcc* links to pthread and of course it depends on how it was configured.

> - Also with that, VLC depends on gcc_s without sources for it.

http://www.gnu.org/licenses/gcc-exception.html

> So it rather looks like Win32 is not maintained.

LOL yeah, and nobody uses it anyway.

> Yeah, JB spends a lot of
> time doing QA and support. Felix A and myself have done some improvements
> and fixes here and there. And you have deteriotated the desktop version for
> the sake of the store variant, *against* review comments from both JB and
> myself. *I* cleaned them up. By that measure, I am paradoxically enough
> closer to Win32 maintainer than you.

ROFL

> Furthermore, I did report several time in the last month build problems.
> JB did some efforts to help me. You did not do anything, even though you
> claim that you would be helping. So sorry, but if anyone is the Windows
> maintainer, that would probably be JB.

Nope I did not do anything.

>> As it breaks win32 builds with only pkg-config and android builds it
>> must be reverted now.
> 
> It unbreaks Win32 builds with "not only" pkg-config.

Oh it breaks setups with custom scripts? Tell me about it.

> I don't understand what's so hard about setting your PKG_CONFIG_LIBDIR
> correctly before calling configure.I also do not understand why you make
> such a controversy out of it; setting environment variables for
> cross-compilation is not exactly new, peculiar, or specific to this patch.

I don't understand what's so hard about committing the needed changes to
the existing scripts together with this commit.

I complained about this exact problem last month after FOSDEM because I knew
you would do it again, case in point.