Hi Sam,
On Sat, Feb 01, 2025 at 12:01:39PM -0700, Sam Hartman wrote:
> Helmut> adding Build-Conflicts: bison. If you'd rather have the
> Helmut> file, I suggest adding Build-Depends-Indep: bison.
>
> Is that sufficient?
I suppose that "that" == "Build-Depends-Indep: bison". The answer is
"mostly". It still fails at is cross building pam in a non-minimal (i.e.
unsupported) build environment that happens to contain bison.
> You also talked about adding native:true for bison. But Is that sufficient?
Sufficient for what? Adding it makes the non-minimal cross build stop
failing.
> Then don't I need to use a native flex and a native C compiler?
flex comes in two parts one is the flex tool (where there is only one)
and the other is libfl-dev containing libfl.so (where you already
build-depend on both). A native C compiler is implied in build-essential
(and crossbuild-essential-*).
> I don't really understand how all that works in meson, but it seems like
> I'd need all native tools to build the spec.
It is assembling an executable() from source files there. While that
results in multiple compiler invocations and a linker invocation, you
only need to specify "native: true" once here. Meson usually is clever
enough to not mix build and host objects.
> I guess we only will consume the spec on the arch all build, and
> there's no reason for arch all to ever cross build I can think of.
I confirm in a Debian context. Outside Debian, people might want to
cross build pam and build its documentation in one go.
> But it seems like we also need to make sure the arch cross builds
> succeed.
Yes. It already does succeed if your build environment is minimal and
thus does not contain bison. If it contains bison (which it should not
do), it presently fails.
> I don't understand how adding build-indep on bison actually fixes the
> problem. I agree it makes it less likely because it means I now need a
Adding b-d-i: bison does not fix my problem. I believe that my problem
needs to be fixed by having a reasonable build environment. What it does
is building that additional documentation file.
> native bison in my build environment rather than a cross bison to
> trigger things.
There is no difference between native and cross bison. Bison translates
one textual format to another and it thus is marked M-A:foreign.
> But if I just make bison (or byacc which is also supported) native,
> won't I try to build using a cross flex, cross compiler and native
> bison?
There also is no cross flex as it is in the same spot as bison except
for also providing a library libfl.so which has been split out of flex
into libfl-dev to allow flex to be M-A:foreign.
> I don't understand how much of the compiler discovery and argument
> detection I would need to replicate to build both cross and native tools.
There is no extra effort. Meson figures out when it needs native and
cross tools and will automatically detect them. It may need a native
libfl.so (but you already depend on that) and flex and bison are
M-A:foreign tools such that there is no cross/native distinction there.
The addition of "native: true" is something I expect upstream to accept
as a generally useful patch and not a Debian-specific workaround
independent of how we solve the other aspects.
> I wonder if a simpler solution would be to only build the spec if we're
> building docs.
I very much welcome not building docs in the arch-only build. It removes
things that may fail from the picture and it also becomes slightly
faster.
> So:
>
> * add bison as build-indep
> * Only build the spec if the docs feature is enabled.
I guess the latter is a matter of adding
-Ddocs=$(if $(filter libpam-doc,$(shell dh_listpackages)),on,off)
to meson_OPTS.
That is solving even more things and it makes the proposed addition of
"native: true" irrelevant to the Debian package, but I suggest still
forwarding it upstream as it serves as documentation for an intention
and it may help other cross distributions such as Yocto.
I hope that this mail answers more questions than it leaves.
Helmut
