Re: [FFmpeg-devel] [RFC] New build system

[Mathieu Duponchelle]

> A newbie question - how would cross-compiling for a target of Win10x64 work, 
> in say ubuntu still eg per zeranoe's method, or rdp's at 
> https://github.com/rdp/ffmpeg-windows-build-helpers ?

meson has excellent support for cross compilation, you can find more info on 
this at


I am not familiar with zeranoe's method or rdp.

-- 
Mathieu
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC] New build system

[Mathieu Duponchelle]

On 07/06/2018 12:46 PM, Tobias Rapp wrote:
>
> What are the dependencies besides Meson and Python v3 itself?

Meson has no hard dependency apart from python3, if the default backend (ninja)
is used, then ninja must indeed also be present on the system.

> Is using Ninja mandatory for building or can Make be used as an alternative?

Make is not an available backend, see 
.

You can find a list of backends at 
.

>
> What happens to build targets when using Meson? Are granular things like 
> "make all", "make doc", "make fate", "make fate-filter-pixfmts" possible?

Yes, when using the ninja backend, you can build individual targets with `ninja 
`.

Note that the fate test suite hasn't been ported to meson (yet).

-- 
Mathieu
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC] New build system

[hydra3333]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of Tobias Rapp
> Sent: Friday, July 6, 2018 8:16 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [RFC] New build system
>
> On 04.07.2018 16:36, Mathieu Duponchelle wrote:
> > [...]
> > 
> > If there are any other questions related to meson or the FFmpeg meson 
> > port please feel free to ask and I'll do my best to answer them.
>
> What are the dependencies besides Meson and Python v3 itself? Is using Ninja 
> mandatory for building or can Make be used as an alternative?
>
> What happens to build targets when using Meson? Are granular things like 
> "make all", "make doc", "make fate", "make fate-filter-pixfmts" possible?
>
> Regards,
> Tobias

A newbie question - how would cross-compiling for a target of Win10x64 work, in 
say ubuntu still eg per zeranoe's method, or rdp's at 
https://github.com/rdp/ffmpeg-windows-build-helpers ?


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC] New build system

[Tobias Rapp]

On 04.07.2018 16:36, Mathieu Duponchelle wrote:

[...]

If there are any other questions related to meson or the FFmpeg meson port
please feel free to ask and I'll do my best to answer them.


What are the dependencies besides Meson and Python v3 itself? Is using 
Ninja mandatory for building or can Make be used as an alternative?


What happens to build targets when using Meson? Are granular things like 
"make all", "make doc", "make fate", "make fate-filter-pixfmts" possible?


Regards,
Tobias

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC] New build system

[Mathieu Duponchelle]

On 07/04/2018 07:01 PM, Carl Eugen Hoyos wrote:
> I don't understand: If everything is enabled and there are
> no options to disable features, how did you (and other
> people in favour of this change) measure performance?


Everything is automatically enabled indeed, but most of the system checks are
however implemented, and the internal dependency check loop has been ported,
making for a pretty fair comparison, if anything the amount of checks is 
probably
higher with the meson port.

Regarding build time (which as I stated is similar), the amount of object files 
being
compiled is also roughly the same.

Given the nature of FFmpeg's build system, a pure apples to apples comparison
is probably be going to be difficult to make, but I think the measurements I 
made
show differences significant enough to be worth mentioning.

-- 
Mathieu
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC] New build system

[Carl Eugen Hoyos]

2018-06-14 18:03 GMT+02:00, Josh de Kock :

> - Exposing options, for now everything is automatically enabled

I don't understand: If everything is enabled and there are
no options to disable features, how did you (and other
people in favour of this change) measure performance?

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC] New build system

[Mathieu Duponchelle]

Hey $list, not an FFmpeg developer, but I worked on the meson port and figured
I could address some of the points that were made.

Since the initial post I have also added support for compiling with Msys/MingW
on Window now in addition to MSVC.

## Performance comparison

A significant part of the discussion has focused on the configure script
being slow, often in a hard-to-predict manner. My findings confirm that:

| Method  | Linux  | Windows (msys-2 / mingw64) | MacOS high sierra 
|
| --- | -- | -- | - 
|
| meson   | 16s    | 1m 2s  | 25s   
|
| ./configure | 1m 21s (506 %) | 13m 5s (1266 %)    | 4m 20s (1040 %)   
|

I have no doubt the configure script could be optimized further, but it
is obviously a pretty complex piece of code, where a meson port would
have the advantage of shifting the burden of optimization to the meson
development team, see https://github.com/mesonbuild/meson/issues/3635 for
example.

The other question is if anyone is actually willing to work on optimising the
configure script, because if not it's a bit of a moot point. And it would have
to be optimised a lot to make it somewhat bearable on Windows again.

Profiling meson is also probably much easier than profiling the configure
script, I noticed one developer reporting their initial attempt at doing
so resulted in a window manager crash. On the other hand, meson recently
added native support for self-profiling, using the `--profile-self` switch
to trigger the creation of a profile graph.

It should be noted that build time does *not* seem to be any different
with meson or make, as FFmpeg's build is already well parallelized.

## Meson development practices

While meson is indeed a relatively new project, it has been adopted by many
projects, GNOME being a prominent one, but neither an early one nor the only
one.

It is neither a GNOME project nor a freedesktop project, you can find
a (non-exhaustive) list of users at http://mesonbuild.com/Users.html. It
has been adopted for example by xorg, wayland, mesa, and VLC could as
far as I understand soon be added to that list as well.

It has a policy of no regressions, and an extensive test suite to ensure
that.

## The port currently depends on meson master

I did debate waiting for a new meson release before publishing my work,
but (perhaps impatiently) decided against it.

The meson port currently depends on two features I added in meson for FFmpeg
specifically:

* A new dictionary built-in type (https://github.com/mesonbuild/meson/pull/3490)
* Native support for generating asm config files 
(https://github.com/mesonbuild/meson/pull/3636)

While I see how this can be used as an argument against the meson port,
my view on that is a bit different, as I think it shows meson's development
team welcomes new features, provided a good case is made for them.

Meson is usable directly from a git checkout, I figured it was a reasonably
low barrier to testing what is still obviously a semi-experimental port.

In any case, all the improvements that were made to meson for the FFmpeg
use case are now part of the latest release, 0.47 
(https://mesonbuild.com/Release-notes-for-0-47-0.html)
which can easily be installed using pip3 if you are not on a distro that
has the latest release.

## Duplicate maintenance burden

That is a very valid point, which an outsider to the project cannot really
argue with. What I can say is that I will be happy to assist with improving
and maintaining the port should the community decide that it would be a
valuable addition, and I am sure I would not be the only one with an interest
in keeping the Meson port up-to-date.

Anyone developing on Windows would likely appreciate it, and any projects that
depend on FFMpeg and use meson themselves as their build system would be able
to use the latest FFmpeg as a meson subproject should they wish to do so
instead of using the system-installed version.

## Points I have not seen discussed

While configure-time performance improvements are a clear advantage, I think
the main reasons a port to meson could prove useful in the long term are
maintainability and accessibility.

I think it is likely that newcomers to FFmpeg development find contributing
to the configure script a bit daunting, and that even long-time FFmpeg
developers must sometimes have a hard time with it.

On the other hand, my experience with meson is that it tends to help with
writing readable and elegant build definitions, I can't think of another
build system that does a better job at that.

If there are any other questions related to meson or the FFmpeg meson port
please feel free to ask and I'll do my best to answer them.

--
Mathieu
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC] New build system

[Stephen Hutchinson]

On 6/18/2018 10:36 AM, Tomas Härdin wrote:

I'm in favor of something changing, because the current slowness is
simply not acceptable. Messing around when adding a new codec or format
and having to wait *seven minutes* between attempts when something is
wrong is a serious motivation killer..

Can't say much about Meson, but CMake+Ninja has been fast enough for my
needs for a long time.



Any solution that allows using Ninja as the build tool (which both Meson
and CMake do) is fine by me.  Alternative configuration systems just 
streamline the process, since they already have the 'generating the 
build.ninja control file' part ready to go (and they'd also solve the

'configure takes way too long' issue as well).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC] New build system

[James Almer]

On 6/18/2018 3:44 PM, Hendrik Leppkes wrote:
> On Mon, Jun 18, 2018 at 8:19 PM Michael Niedermayer
>  wrote:
>>
>> On Mon, Jun 18, 2018 at 06:52:18PM +0200, Nicolas George wrote:
>>> Tomas Härdin (2018-06-18):
 Others have mentioned this already, but it bears repeating: the build
 (make) isn't what's so slow, configure is. I went ahead and did some
 profiling on it based on the StackOverflow thread that pops up when one
 Web-searches "bash profiling" [1]. I went with what the second guy in
 there says, because the first method eventually invokes the OOM killer.
>>>
>>> Before that, I suspect it would have been interesting to test a
>>> configure from two years ago, and bissecting if it happens to be much
>>> faster.
>>
>> The speed of configure declined very significantly over time, here are some
>> quick tests, not full bisects:
>>
>> but theres another point which i have not seen anyone make but maybe i missed
>> it.
>> If changes which decrease speed go in unhindered and without correction then 
>> no
>> system, not a custom one, no meson no autotools, no cmake is guranteed to
>> prevent such speed decline.
>> Of course some of the decline will be due to added features and the added 
>> tests
>> they need.
>>
> 
> The biggest recent slowdown is undoubtly from the change to how
> depdencies are resolved, but the result of the change is also a much
> better outcome in selected link libraries and generated pkg-config
> files (only those appropriate for a specified library, instead of all
> of them).
> Of course one could try to investigate to implement the same thing
> differently, but shell is really getting at its limit there.

Unless the same can be achieved without spawning a new bash process for
every single dep check, then there's not much we can do with shell to
improve the current situation.

So i agree moving onto something else, like a pure python 3 script,
might be a good idea. I'm not sure about Meson since it definitely will
be a pain on non standard systems, not to mention the PoC submitted
doesn't even work with a release currently actually available on any
package manager.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC] New build system

[Hendrik Leppkes]

On Mon, Jun 18, 2018 at 8:19 PM Michael Niedermayer
 wrote:
>
> On Mon, Jun 18, 2018 at 06:52:18PM +0200, Nicolas George wrote:
> > Tomas Härdin (2018-06-18):
> > > Others have mentioned this already, but it bears repeating: the build
> > > (make) isn't what's so slow, configure is. I went ahead and did some
> > > profiling on it based on the StackOverflow thread that pops up when one
> > > Web-searches "bash profiling" [1]. I went with what the second guy in
> > > there says, because the first method eventually invokes the OOM killer.
> >
> > Before that, I suspect it would have been interesting to test a
> > configure from two years ago, and bissecting if it happens to be much
> > faster.
>
> The speed of configure declined very significantly over time, here are some
> quick tests, not full bisects:
>
> but theres another point which i have not seen anyone make but maybe i missed
> it.
> If changes which decrease speed go in unhindered and without correction then 
> no
> system, not a custom one, no meson no autotools, no cmake is guranteed to
> prevent such speed decline.
> Of course some of the decline will be due to added features and the added 
> tests
> they need.
>

The biggest recent slowdown is undoubtly from the change to how
depdencies are resolved, but the result of the change is also a much
better outcome in selected link libraries and generated pkg-config
files (only those appropriate for a specified library, instead of all
of them).
Of course one could try to investigate to implement the same thing
differently, but shell is really getting at its limit there.

- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC] New build system

[Michael Niedermayer]

On Mon, Jun 18, 2018 at 06:52:18PM +0200, Nicolas George wrote:
> Tomas Härdin (2018-06-18):
> > Others have mentioned this already, but it bears repeating: the build
> > (make) isn't what's so slow, configure is. I went ahead and did some
> > profiling on it based on the StackOverflow thread that pops up when one
> > Web-searches "bash profiling" [1]. I went with what the second guy in
> > there says, because the first method eventually invokes the OOM killer.
> 
> Before that, I suspect it would have been interesting to test a
> configure from two years ago, and bissecting if it happens to be much
> faster.

The speed of configure declined very significantly over time, here are some
quick tests, not full bisects:

but theres another point which i have not seen anyone make but maybe i missed
it.
If changes which decrease speed go in unhindered and without correction then no
system, not a custom one, no meson no autotools, no cmake is guranteed to
prevent such speed decline.
Of course some of the decline will be due to added features and the added tests
they need.

also the speed seems worse with bash so anyone wanting a quick fix, do not use
bash for configure.

(note /bin/sh is dash here on my ubuntu box, and that is used by default i 
think)

master:
bash ./configure ; time bash ./configure
real0m56.345s
user0m43.532s
sys 0m15.668s

./configure ; time ./configure
real0m15.788s
user0m8.469s
sys 0m9.677s

dash ./configure --cc='ccache gcc' --tempprefix=/home/michael/fftmpconf ; time 
dash ./configure --cc='ccache gcc' --tempprefix=/home/michael/fftmpconf
real0m13.982s
user0m7.591s
sys 0m8.693s


release/4.0:
bash ./configure ; time bash ./configure
real0m56.337s
user0m43.207s
sys 0m15.988s

./configure ; time ./configure
real0m15.704s
user0m8.352s
sys 0m9.713s

dash ./configure --cc='ccache gcc' --tempprefix=/home/michael/fftmpconf ; time 
dash ./configure --cc='ccache gcc' --tempprefix=/home/michael/fftmpconf
real0m13.966s
user0m7.414s
sys 0m8.877s


release/3.4:
bash ./configure ; time bash ./configure
real0m21.324s
user0m18.041s
sys 0m3.693s

./configure ; time ./configure
real0m6.756s
user0m4.158s
sys 0m2.822s

dash ./configure --cc='ccache gcc' --tempprefix=/home/michael/fftmpconf ; time 
dash ./configure --cc='ccache gcc' --tempprefix=/home/michael/fftmpconf
real0m4.849s
user0m2.887s
sys 0m2.148s


release/3.0:
bash ./configure ; time bash ./configure
real0m16.955s
user0m13.770s
sys 0m3.485s

./configure ; time ./configure
real0m6.006s
user0m3.616s
sys 0m2.602s

dash ./configure --cc='ccache gcc' --tempprefix=/home/michael/fftmpconf ; time 
dash ./configure --cc='ccache gcc' --tempprefix=/home/michael/fftmpconf
real0m4.269s
user0m2.401s
sys 0m2.034s


release/2.0:
bash ./configure ; time bash ./configure
real0m11.050s
user0m8.855s
sys 0m2.465s

./configure ; time ./configure
real0m4.443s
user0m2.622s
sys 0m1.983s


release/1.0:
bash ./configure ; time bash ./configure
real0m14.104s
user0m10.045s
sys 0m4.852s

./configure ; time ./configure
real0m4.712s
user0m2.250s
sys 0m2.761s


release/0.7:
bash ./configure ; time bash ./configure
real0m9.441s
user0m6.607s
sys 0m3.363s

./configure ; time ./configure
real0m3.346s
user0m1.583s
sys 0m1.960s


release/0.6:
bash ./configure ; time bash ./configure
real0m5.679s
user0m3.431s
sys 0m2.674s

./configure ; time ./configure
real0m2.670s
user0m1.276s
sys 0m1.556s


release/0.5:
bash ./configure ; time bash ./configure
real0m5.107s
user0m3.310s
sys 0m2.076s

./configure ; time ./configure
real0m1.949s
user0m0.893s
sys 0m1.190s


[...]


-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC] New build system

[Nicolas George]

Tomas Härdin (2018-06-18):
> Others have mentioned this already, but it bears repeating: the build
> (make) isn't what's so slow, configure is. I went ahead and did some
> profiling on it based on the StackOverflow thread that pops up when one
> Web-searches "bash profiling" [1]. I went with what the second guy in
> there says, because the first method eventually invokes the OOM killer.

Before that, I suspect it would have been interesting to test a
configure from two years ago, and bissecting if it happens to be much
faster.

No time to reply more now.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC] New build system

[Tomas Härdin]

tor 2018-06-14 klockan 17:03 +0100 skrev Josh de Kock:
> Any comments, and thoughts on a new build system would be much 
> appreciated including concerns regarding it.

Others have mentioned this already, but it bears repeating: the build
(make) isn't what's so slow, configure is. I went ahead and did some
profiling on it based on the StackOverflow thread that pops up when one
Web-searches "bash profiling" [1]. I went with what the second guy in
there says, because the first method eventually invokes the OOM killer.

Running configure with this timing method generates about 350 MiB of
data. Pasting, sorting and cutting line lengths down to 80 chars
yields  205 MiB, ~4M lines:

./pastem.sh sample-time.3099 > xxpasted
sort -r -n xxpasted | cut -c -80 > xxsorted

The top of the result looks like this, for a ./configure with a wall
time of 7 minutes(!):

> 1529328268.431696969+ LC_ALL=C
>  0.409855126+ enable makeinfo
>  0.363928815++ echo
>  0.311682872+ append CXXFLAGS -std=c++11
>  0.269393447+ '[' 06 -ge 5 ']'
>  0.138258064+ enable pod2man
>  0.106506505+ case 'hq_hqa_decoder_extralibs' in
>  0.096331014+ enable ebp_available
>  0.088183898+ enabled cross_compile
>  0.088088085++ echo -I/usr/include/alsa
>  0.076656112++ dep_any_level=1
>  0.072606939+ for func in $COMPLEX_FUNCS
>  0.068691315+ enable snd_pcm_htimestamp
>  0.067642785++ echo
>  0.055935755+ enable flt_lim
>  0.055764002+++ echo
>  0.055377041+ enable const_nan
>  0.053997618+++ echo
>  0.053772963+++ echo
>  0.053206037+++ echo
>  0.052331662+++ echo
>  0.051481411+++ echo
>  0.049535905+++ echo
>  0.048992642+++ echo
>  0.048822862+ enable getopt
>  0.048404893++ echo
>  0.047455682+++ echo
>  0.047416869+++ echo
>  0.047386485++ echo -pthread
>  0.047302549+ add_ldflags -Wl,-rpath-
link=libpostproc:libswresample:libswscale:
>  0.047291743+ enable_sanitized 'struct addrinfo'
>  0.047267974+++ echo
>  0.047259671+++ echo
>  0.047095523+++ echo
>  0.047060081+ check_func getopt
>  0.046771877+++ echo
>  0.046585371+++ echo
>  0.046355111+++ echo
>  0.046201711+++ echo
>  0.045938850+++ echo
>  0.045876554+++ echo

Most of the file is crap like this.

enable() and append() are just doing the equivalent of adding to lists
and hashes. This is slower than it needs to be partly because configure
doesn't make use of some useful bashisms (I guess to maintain BSD
compat?)

I'm in favor of something changing, because the current slowness is
simply not acceptable. Messing around when adding a new codec or format
and having to wait *seven minutes* between attempts when something is
wrong is a serious motivation killer..

Can't say much about Meson, but CMake+Ninja has been fast enough for my
needs for a long time.

/Tomas

[1] https://stackoverflow.com/questions/5014823/how-to-profile-a-bash-s
hell-script-slow-startup
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC] New build system

[Carl Eugen Hoyos]

2018-06-15 2:16 GMT+02:00, Martin Herkt :

> FFmpeg’s build system is unique because despite its lack
> of caching, one must sometimes make clean and
> reconfigure everything when bisecting for bugs.

Yes, this is unavoidable (make cannot know about new
features without running configure).

> Maybe depfile generation is buggy or someting.

This is at least not a known issue (but see above).

> In any case, it’s super annoying.

How often do you bisect FFmpeg?
I did it (at least) several hundred times over the last years,
and it very rarely was a problem (if there was an issue,
then because of the nature of the bug, see #3440 or #7058).

> Then there’s the slowness

That we should work on.

> and make’s suboptimal job distribution on multi-core
> systems

How can I reproduce this? As said, building FFmpeg on
a multi-core system (with very slow cores) is extremely
fast.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC] New build system

[Martin Herkt]

On Friday, June 15, 2018 12:45:53 AM CEST Jean-Baptiste Kempf wrote:
> Hello,
> 
> On Thu, 14 Jun 2018, at 18:03, Josh de Kock wrote:
> > As such, I'd like to propose adopting a new build system to FFmpeg,
> > namely Meson[1]. There has already been a fair amount of work (not by
> 
> I think this is a great idea.
> 
> Custom buildsystem are almost always wrong and/or broken.
> Beside autotools (and sometimes CMake), everything is always broken on a
> system or another.

As an “outsider” who only (cross-)builds and packages FFmpeg, I concur. Except 
that CMake is always broken everywhere and under all circumstances unless you 
go out of your way to emulate sane behavior, at which point you have even more 
boilerplate than with custom Makefiles, and it still won’t work on anything 
you haven’t tested. Meson on the other hand is one of the very few build 
systems that actually care about packagers.

FFmpeg’s build system is unique because despite its lack of caching, one must 
sometimes make clean and reconfigure everything when bisecting for bugs. Maybe 
depfile generation is buggy or someting. In any case, it’s super annoying. 
Then there’s the slowness and make’s suboptimal job distribution on multi-core 
systems and distributed builds. Not something I’d want to suffer during 
development.

I think Meson is still a little immature in some places, but an effort should 
be made nonetheless. My experiences with it have been very positive, and the 
documentation had answers to all of my questions. It’s easy to figure out and 
there are few surprises, which is something I cannot say about shell scripts.

Its codebase is also fairly lean compared to some of the alternatives and its 
developers seem open to changes, so all hope isn’t lost if there’s something 
fundamentally wrong with it.

> And they don't want it to be turing-complete, which is great, and avoids
> creating a monster.

Some people might disagree with this and call it another CMake due to its 
custom language (which is as far from the truth as it gets), but it’s a good 
thing indeed. A mostly declarative build system which delegates complex tasks 
to external scripts with clear responsibilities (and provides some 
introspection) is much nicer to work with than a fat monolith with intermixed 
dependency testing, file template processing logic and stack machines.

I think you should at least give it a try.

signature.asc
Description: This is a digitally signed message part.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC] New build system

[Carl Eugen Hoyos]

2018-06-14 23:50 GMT+02:00, Rostislav Pehlivanov :
> On 14 June 2018 at 19:56, Nicolas George  wrote:
>
>> Josh de Kock (2018-06-14):
>> > As such, I'd like to propose adopting a new build system to FFmpeg,
>> namely
>> > Meson[1].
>>
>> I am very strongly against this.
>>
>> I loathe make and all it has to do with it, but really, for a project
>> like this, it is the only viable option. The principles of make are
>> already known by almost all potential Libre software developers, those
>> in the project and those not yet.
>>
>>
> No, it isn't. Maybe if you took a moment to look at the proposed branches
> you'd notice NONE Of them remove ./configure. In fact that's precisely the
> plan - to leave and still support the script for the forseeable future.
> Hence your predjudice is unjustified. This simply adds support for a faster
> build system to those who wish to use it.

This sounds like a duplicate maintenance burden to me.
Maybe the effort should go into accelerating our current
script?

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC] New build system

[Jean-Baptiste Kempf]

Hello,

On Thu, 14 Jun 2018, at 18:03, Josh de Kock wrote:
> As such, I'd like to propose adopting a new build system to FFmpeg, 
> namely Meson[1]. There has already been a fair amount of work (not by 

I think this is a great idea.

Custom buildsystem are almost always wrong and/or broken.
Beside autotools (and sometimes CMake), everything is always broken on a system 
or another.

The FFmpeg configure is an exception, because it's quite good; however it is 
far from being bug-free, in my experience.
Showing those bugs in this configure got me some rages from old developers, 
which is why I usually don't mention them. 

It is also quite slow, notably the part where you have nothing shown for a long 
time, before getting any output. And sometimes you need to repeat over and 
over, in order to fix that.

But it was not really worse than other solutions.

However, meson is way better than autotools, and wayyy better than CMake. And I 
will also says that it is better than the configure.
It's also done by people who understand what cross-compilation is, so that's a 
good point. And they don't want it to be turing-complete, which is great, and 
avoids creating a monster.

So, +1 from me.

-- 
Jean-Baptiste Kempf -  President
+33 672 704 734
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC] New build system

[Paul B Mahol]

On 6/15/18, James Almer  wrote:
> On 6/14/2018 7:10 PM, Paul B Mahol wrote:
>> On 6/14/18, Nicolas George  wrote:
>>> Rostislav Pehlivanov (2018-06-14):
 No, it isn't. Maybe if you took a moment to look at the proposed
 branches
 you'd notice NONE Of them remove ./configure. In fact that's precisely
 the
 plan - to leave and still support the script for the forseeable future.
 Hence your predjudice is unjustified. This simply adds support for a
 faster
 build system to those who wish to use it.
>>>
>>> So, code duplication? Charybde rather than Scylla...
>>
>> Your opinions are worthless.
>
> And you're not adding anything to the discussion.
>
> Drop it already, you're being extremely aggravating these past months
> for no reason whatsoever.

I will not, simply because he likes to block everything he doesn't like or
understands.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC] New build system

[James Almer]

On 6/14/2018 7:10 PM, Paul B Mahol wrote:
> On 6/14/18, Nicolas George  wrote:
>> Rostislav Pehlivanov (2018-06-14):
>>> No, it isn't. Maybe if you took a moment to look at the proposed branches
>>> you'd notice NONE Of them remove ./configure. In fact that's precisely
>>> the
>>> plan - to leave and still support the script for the forseeable future.
>>> Hence your predjudice is unjustified. This simply adds support for a
>>> faster
>>> build system to those who wish to use it.
>>
>> So, code duplication? Charybde rather than Scylla...
> 
> Your opinions are worthless.

And you're not adding anything to the discussion.

Drop it already, you're being extremely aggravating these past months
for no reason whatsoever.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC] New build system

[Paul B Mahol]

On 6/14/18, Nicolas George  wrote:
> Rostislav Pehlivanov (2018-06-14):
>> No, it isn't. Maybe if you took a moment to look at the proposed branches
>> you'd notice NONE Of them remove ./configure. In fact that's precisely
>> the
>> plan - to leave and still support the script for the forseeable future.
>> Hence your predjudice is unjustified. This simply adds support for a
>> faster
>> build system to those who wish to use it.
>
> So, code duplication? Charybde rather than Scylla...

Your opinions are worthless.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC] New build system

[Nicolas George]

Rostislav Pehlivanov (2018-06-14):
> No, it isn't. Maybe if you took a moment to look at the proposed branches
> you'd notice NONE Of them remove ./configure. In fact that's precisely the
> plan - to leave and still support the script for the forseeable future.
> Hence your predjudice is unjustified. This simply adds support for a faster
> build system to those who wish to use it.

So, code duplication? Charybde rather than Scylla...

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC] New build system

[Rostislav Pehlivanov]

On 14 June 2018 at 19:56, Nicolas George  wrote:

> Josh de Kock (2018-06-14):
> > As such, I'd like to propose adopting a new build system to FFmpeg,
> namely
> > Meson[1].
>
> I am very strongly against this.
>
> I loathe make and all it has to do with it, but really, for a project
> like this, it is the only viable option. The principles of make are
> already known by almost all potential Libre software developers, those
> in the project and those not yet.
>
>
No, it isn't. Maybe if you took a moment to look at the proposed branches
you'd notice NONE Of them remove ./configure. In fact that's precisely the
plan - to leave and still support the script for the forseeable future.
Hence your predjudice is unjustified. This simply adds support for a faster
build system to those who wish to use it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC] New build system

[Hendrik Leppkes]

On Thu, Jun 14, 2018 at 9:05 PM Nicolas George  wrote:
>
> Hendrik Leppkes (2018-06-14):
> > I don't mind make itself, for me its configure thats the real problem.
> > Its extremely slow (we're talking minutes), for me often taking longer
> > then the actual compilation (especially with ccache) - and that is
> > really extremely painful.
>
> IIRC, a change from the fork that was merged in the last few months made
> configure much much slower. It could bear investigating.
>
> Yet, the arguments for make apply to configure too: it is written in
> standard shell script, not some newfangled system that only a few people
> know.
>

And that exactly is the problem. Shell is horrible for this. It wants
to be a real programming language but it just isn't.
You could re-write configure in any actual language and so many of
these problems would just be gone, and keep the remaining part of the
build system as-is even.

- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC] New build system

[Nicolas George]

Hendrik Leppkes (2018-06-14):
> I don't mind make itself, for me its configure thats the real problem.
> Its extremely slow (we're talking minutes), for me often taking longer
> then the actual compilation (especially with ccache) - and that is
> really extremely painful.

IIRC, a change from the fork that was merged in the last few months made
configure much much slower. It could bear investigating.

Yet, the arguments for make apply to configure too: it is written in
standard shell script, not some newfangled system that only a few people
know.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC] New build system

[Hendrik Leppkes]

On Thu, Jun 14, 2018 at 8:56 PM Nicolas George  wrote:
>
> Josh de Kock (2018-06-14):
> > As such, I'd like to propose adopting a new build system to FFmpeg, namely
> > Meson[1].
>
> I am very strongly against this.
>
> I loathe make and all it has to do with it, but really, for a project
> like this, it is the only viable option. The principles of make are
> already known by almost all potential Libre software developers, those
> in the project and those not yet.
>
> Make is also a very mature system, with many interoperable
> implementations; and although FFmpeg relies on a lot of extensions that
> are specific to GNU make, these extensions themselves are very mature
> and I think implemented in a few other versions. It is completely
> different from using a very young project that has only a single
> implementation and that still evolves so much that you did not manage to
> use a released version.
>
>

I don't mind make itself, for me its configure thats the real problem.
Its extremely slow (we're talking minutes), for me often taking longer
then the actual compilation (especially with ccache) - and that is
really extremely painful.
configure is also whats causing all those headaches, not make.

- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC] New build system

[Nicolas George]

Josh de Kock (2018-06-14):
> As such, I'd like to propose adopting a new build system to FFmpeg, namely
> Meson[1].

I am very strongly against this.

I loathe make and all it has to do with it, but really, for a project
like this, it is the only viable option. The principles of make are
already known by almost all potential Libre software developers, those
in the project and those not yet.

Make is also a very mature system, with many interoperable
implementations; and although FFmpeg relies on a lot of extensions that
are specific to GNU make, these extensions themselves are very mature
and I think implemented in a few other versions. It is completely
different from using a very young project that has only a single
implementation and that still evolves so much that you did not manage to
use a released version.

Add to that that this Meson comes from the GNOME / freedesktop crowd,
who is not known for its attachment to durability and API stability.
From where I stand, Meson is the new autotools; maybe in ten years we
will be able to observe that it was really a progress compared to
autotools. But in the meantime, there are reasons for FFmpeg to have
avoided autotools like plague, and they apply to Meson the same.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel