[vlc-devel] [PATCH 2/4] doc: add an option to build libvlc sample app from the documentation

Mon Mar 1 10:15:45 UTC 2021

On 1 Mar 2021, at 7:41, Steve Lhomme wrote:

> This is not a file we use in our build system. It's there for 
> documentation purpose, to guide users.
> That doesn't mean there's only one way to build Qt project. We use 
> autotools to build our own Qt module. In the past I've used others as 
> well. I believe nowadays CMAKE is also a candidate. We'll probably use 
> Meson for it as well.
> Pushing for qmake here when we already have all the autotools parts 
> ready and solid to do it make no sense to me.
>
>
> Otherwise you should advocate to add MSVC projects for libvlc and 
> build windows samples with it since that's what a lot of people will 
> use.
>

I agree with what Alexandre already wrote, duplicating the build in 
autotools here seems incredibly awful choice
for nearly no benefit at all… Just use qmake to build the sample 
project, like most users of it would do?
I am not sure who would benefit from having another build for this in 
autotools, which can be painful to use
properly with Qt, or nearly impossible even, on macOS. And additionally 
can easily get out of sync when
someone is unaware of the other build system for it and makes changes 
only updating the autotools build for it…

Your point about MSVC does not really make sense to me, as this is a 
completely different topic, really.

>> On 27 Feb 2021, at 20:15, Alexandre Janniaux <ajanni at videolabs.io> 
>> wrote:
>>
>> On Sat, Feb 27, 2021 at 06:20:49PM +0100, Steve Lhomme wrote:
>>>> On 2/27/2021 3:56 PM, Alexandre Janniaux wrote:
>>>> Hi,
>>>>
>>>> On Sat, Feb 27, 2021 at 10:48:43AM +0100, Steve Lhomme wrote:
>>>>> On 2021-02-26 18:16, Alexandre Janniaux wrote:
>>>>>> Hi,
>>>>>>
>>>>>> As mentioned privately, I'm not fond of adding yet another build
>>>>>> system to build examples, especially since it won't even be 
>>>>>> testing
>>>>>> the buildsystem final users are supposed to use.
>>>>>
>>>>> There is not "yet another build system" in this patch.
>>>>
>>>> Sorry, what? you litterally create doc/libvlc/Makefile.am
>>>> typically to build QtGL and QtPlayer with new automake
>>>> targets and even new automake rules whereas there is already
>>>> a qmake-based build system.
>>>
>>> Our "build system" is autotools. I just use that.
>>> Please point me to the "qmake-based build system" we already use.
>>
>> https://code.videolan.org/videolan/vlc/-/blob/master/doc/libvlc/QtGL/QtGl.pro
>>
>>>> With that, both can now get out-of-sync with regards to the
>>>> other one, and one of them is even never used in the CI while
>>>> the other would always be used. Better remove the other one
>>>> like I mentioned then, but as I said:
>>>>
>>>>  - users will never build their application from the VLC build
>>>>    directory.
>>>>
>>>>  - most Qt users will typically never use automake to build a
>>>>    Qt application, so it seems like a bad target for
>>>>    documentation.
>>>>
>>>>  - in addition, it means that you need to build libvlc in order
>>>>    to build the examples, which is quite inconvenient since you
>>>>    could be able to ship the examples with a packaged libvlc.
>>>>
>>>>> The final users are free to use whatever they want and that's a 
>>>>> good reason
>>>>> not to orientate them in any favored direction.
>>>>
>>>>  - and I completely agree with this point right above, which is
>>>>    why using automake within the same autoconf package is a bad
>>>>    idea, since it will never be the same environment for other
>>>>    buildsystem, by-pass potential dependency detection systems
>>>>    and thus is quite opinionated. But more on this in next
>>>>    paragraph.
>>>>
>>>>>
>>>>>> I'd prefer that we typically use make install to a given prefix 
>>>>>> and
>>>>>> then use qmake/foomake/etc with the correct PKG_CONFIG_PATH. The
>>>>>> alternative is to use only the automake buildsystem but to be 
>>>>>> fair,
>>>>>
>>>>> Last time I proposed a similar patch, Rémi advised to use 
>>>>> "noinst_" instead
>>>>> of "bin_" prefix. And IMO it makes sense not to install sample 
>>>>> code. The
>>>>> solution you propose is the opposite, it requires to install 
>>>>> libvlc before
>>>>> building the samples. Something that is not needed by us nor the 
>>>>> end user
>>>>> who will need to repackage the build anyway.
>>>>
>>>> There's a huge difference between "do not install the examples"
>>>> (which makes perfect sense because users generally don't need
>>>> them on their systems) and "do not install libvlc".
>>>>
>>>> Typically, if you don't install libvlc, but use the mock plugins
>>>> in the examples, it might work with the automake buildsystem you
>>>> wrote but won't work with a packaged VLC and an external build
>>>> system, because mock plugin is not installed.
>>>>
>>>> So I really fail to see how it's the opposite.
>>>>
>>>> In addition, if libvlc needs to be repackaged (which imho is
>>>> already a flaw in our buildsystem since it bypass the make
>>>> install behaviour and is another layer above the buildsystem
>>>> which actually mimic the layer below instead of using it), then
>>>> we just need to actually package libvlc in the CI before using
>>>> it in the examples.
>>>>
>>>>>> what are the odds that final users are building their application
>>>>>> inside libvlc buildsystem without having an installed package?
>>>>>
>>>>> Maybe it's customary on Linux (is there a separate libvlc package 
>>>>> on Linux
>>>>> distros ?) but on Windows or Mac or Android or iOS they will need 
>>>>> to package
>>>>> libvlc by their own means, with their build system. So the way we 
>>>>> build it
>>>>> for ourself will not have much impact.
>>>>
>>>> I don't think many people wants to be compiling libvlc
>>>> themselves, even on Windows, and especially on Windows.
>>>>
>>>> But anyway say that this is true. Why use libvlc from
>>>> the build directory instead of using libvlc from the
>>>> packaged directory then?
>>>>
>>>> Then, yes, we have tools to detect dependencies much like
>>>> any other platforms. We don't typically use additional
>>>> layer of dependency management like Conan but the user
>>>> might use that to provide libvlc support. By using external
>>>> build system (and actually any external buildsystem), we
>>>> show the user how it can use it to build with libvlc with
>>>> minor tweaking to the dependency layer, be it cmake, meson,
>>>> qmake, conan or anything other used on Windows. How is using
>>>> uninstalled libtool library which almost none of the above
>>>> buildsystem understand is less opinionated than using the
>>>> idiomatic buildsystem used within the community the examples
>>>> are made for?
>>>>
>>>> Just so this message is clear, I'd be happy that we test the
>>>> examples in the CI and I'm glad that you initiated work
>>>> regarding that. But honestly even the previous buildsystem
>>>> was broken last time I used it and I had to fix it, I don't
>>>> want another maintenance burden there and especially if it
>>>> gives no additional value to the enduser.
>>>>
>>>> The --enable-doc-samples can still be in place in configure
>>>> with much less code and without duplicating the current work.
>>>>
>>>> Regards,
>>>> --
>>>> Alexandre Janniaux
>>>> Videolabs
>>>> _______________________________________________
>>>> vlc-devel mailing list
>>>> To unsubscribe or modify your subscription options:
>>>> https://mailman.videolan.org/listinfo/vlc-devel
>>>>
>>>
>>>
>>> _______________________________________________
>>> vlc-devel mailing list
>>> To unsubscribe or modify your subscription options:
>>> https://mailman.videolan.org/listinfo/vlc-devel
>> _______________________________________________
>> vlc-devel mailing list
>> To unsubscribe or modify your subscription options:
>> https://mailman.videolan.org/listinfo/vlc-devel
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel