Hi Mauro,
On 18/05/2021 08:23, Mauro Carvalho Chehab wrote:
> Em Mon, 17 May 2021 23:13:45 +0100
> Kieran Bingham <kieran.bingham@xxxxxxxxxxxxxxxx> escreveu:
>
>> Ah, yes I should have been clearer there - but they don't do 'anything'
>> except the bare minimum for both:
>>
>> ----------
>> kbingham@Q:/opt/projects/media/v4l-utils$ cat make-autoconf.sh
>> #!/bin/sh
>>
>> export CCACHE_DISABLE=true
>>
>> rm -rf build-autoconf
>> mkdir -p build-autoconf
>> cd build-autoconf
>> ../configure
>
> This is not the bare minimum. It is just the opposite: the way we
Ok, I'm sorry - I need to be clearer about my being clearer.
My *scripts* don't do anything except the bare minimum to build.
I pulled out the simplest commands to build both versions so that the
times could be compared.
- Autoconf
mkdir; ../configure; make
- Meson
meson build; ninja
I expected no parameters to be passed
(Yes, I played with these in the last reply to see the effects suggested
by Ariel, but I shouldn't have to)
> intentionally implemented configure.ac is to auto-detect as much as possible
> what tools are supported and to build the maximum number of features as
> possible.
Agreed, I expect both sides to auto-detect the most features that are
possible to build on a given configuration by default, *and* I expect
both versions to detect the same.
> See, when one calls:
>
> $ ./configure
>
> It will display at the end the optional features that were enabled
> that we found important enough to report:
>
> compile time options summary
> ============================
>
> Host OS : linux-gnu
> X11 : yes
> GL : yes
> glu : yes
> libelf : yes
> libjpeg : yes
> libudev : yes
> pthread : yes
> QT version : v5.4 with QtGL
> ALSA support : yes
> SDL support : yes
>
> build dynamic libs : yes
> build static libs : yes
>
> gconv : no
>
> dynamic libv4l : yes
> v4l_plugins : yes
> v4l_wrappers : yes
> libdvbv5 : yes
> dvbv5-daemon : yes
> v4lutils : yes
> qv4l2 : yes
> qvidcap : yes
> v4l2-ctl uses libv4l : yes
> v4l2-ctl-32 : no
> v4l2-compliance : yes
> v4l2-compliance uses libv4l: yes
> v4l2-compliance-32 : no
> BPF IR Decoders: : no
>
> a bare minimum setting would print most (if not all) above features
> as "no".
This is a mis-communication. I said (or intended to say?) my scripts do
the bare minimum.
I agree, if we want to compare both build systems; building the bare
minimum - then that list would be full of no's - but why would we want
to compare two build systems doing nothing.
ok, so that might be one data point, but not one I'm interested in
comparing. I want to see what differences occur between both build
systems building everything, and ensure that both produce the same result.
It would likely be useful to get a summary() of what is and isn't built
from the meson to produce a comparable output summary.
> See, we never treated internationalization or documentation as
> features. So, it won't display anything about that. It will just
> build docs and .po files by default, if the needed tools and
> libraries are present at the building system.
I think that's fine (building when possible).
I think the meson build (in my system configuration) didn't do this,
lets call that a bug in the current meson version. I've tried to
highlight that in the previous e-mail.
We need to do testing of different cases to make sure that the features
are comparable across both systems.
That's what I was trying to do.
> Yet, autotools have some options that could disable building them.
> ./configure --help is your friend[1], if you want a bare minimum
> build.
Yes, I'm aware of these options. A 'bare minimum build' was not my goal.
> [1] You can see most of the options that can be enabled/disabled with:
>
> ./configure --help|grep -E '(enable|disable|with)'
>
> The command would be similar to:
>
> ./configure --disable-nls --disable-libdvbv5 --disable-dyn-libv4l --disable-v4l-utils --disable-v4l2-compliance-libv4l --disable-v4l2-ctl-libv4l --disable-qv4l2 --disable-qvidcap --disable-bpf --without-jpeg --without-libudev --disable-gconv --disable-doxygen-doc --disable-doxygen-dot --disable-doxygen-html --disable-doxygen-ps --disable-doxygen-pdf
>
> here, after running the above, building with autoconf was very fast.
>
> $ make clean
> $ time CCACHE_DISABLE=true make -j8
> real 0m4,594s
> user 0m14,050s
> sys 0m1,613s
This isn't what I've been comparing.
I have been trying to (or I want to) compare the performance differences
of two *full* builds on the same system. I'm sorry that my language on
the previous e-mail caused confusion there.
To clarify, I expect a
minimal build script (*no parameters passed*)
to provide a
maximal build configuration (everything that could be built).
And I would expect both sides to produce the same feature set.
If they don't - then it should be fixed.
>> meson build-meson
>> ninja -C build-meson
>
> I would be expecting that the above would do the same, but
> it sounds it is lacking a lot of things...
meson build-meson; ninja -C build-meson should be building a maximal
configuration. (if it isn't, that's something to look at)
As identified, I think there are things missing, or not yet the same
which is why I've been highlighting the size of the build directories.
In particular I'm highlighting the fact that I have observed
internationalisation files are missing.
>>>> du -sh build-autoconf build-meson/
>>>> 129M build-autoconf
>>>> 69M build-meson/
However I do not think that difference alone can account for a 60MB
difference.
> as otherwise the difference won't be so huge.
>
Agreed.
> See, you're comparing very different things, as autotools is clearly
> doing a lot more than meson. If they were building the same thing, I
> would expect a difference at the order of tens of KB at most, due to
> temporary/cache files, build logs and, in the case of autotools, m4
> files. Neither of those are huge.
Agreed.
Something is missing, that's to be investigated. That's why I've been
highlighting the difference in build output size specifically. But I do
not know what the difference is. I just built them together.
Re-reading my mail from last night - it looks like I was being overly
enthusiastic on the speed differences. I'm sorry - it was late, and I
was giddy watching it fly by. (The things people do for fun hey)
I was reporting that they are not building the same output, so I
shouldn't have made any comment on comparing speeds until they are
producing identical outputs.
> Assuming that both builds used the same compilers, a difference at
> the order of (tens of) MB can only be explained if Meson build
> was very incomplete, and/or the output files don't carry the same
> debug info.
Indeed - compiler debug info level changes could be another thing to
check. That could account for a larger build output difference, but
there's certainly a large discrepancy to solve.
--
Regards
--
Kieran
