Hi Sam,
On Mon, Feb 03, 2025 at 01:16:26AM -0700, Sam Hartman wrote:
> Well, makes your particular case stop failing.
> I guess I was asking whether adding native=true to finding bison is
> sufficient to get the spec built if a native bison is present.
What you write makes me guess that there still is a misunderstanding.
Qualifying bison as "native" does not make sense. It translates one
textual format (yacc grammar) to another textual format (C source). Its
behaviour is not dependent on the architecture.
The next part is that the native=true I propose to add has nothing to do
with bison. It applies to the compiler being used to compile the sources
generated by bison
I confirm that with the proposed patch and bison installed, the spec is
produced both in native and in cross builds.
> I was more thinking about the Meson side of things rather than the
> Debian side of things.
> Do I need to duplicate the logic to choose compiler flags and to set up
> config.h for the cross side as well as the native side?
I suspect that you believe that the line
cc = meson.get_compiler('c')
chooses a compiler. This is not the case. The compiler is automatically
chosen whether you ask meson for the compiler object or not. The same
holds for (some of the) compiler flags. When adding native=true to an
executable(), meson will implicitly call meson.get_compiler() and
forward the native flag and thus this all just works.
Whether you need a config.h depends on whether you use it in the sources
being compiled. The relevant .y and .l files do #include <config.h>, so
in principle you do, because the contents of config.h typically are
architecture-dependent. Practically speaking, it does work without
adding supplying one. I attempted a rebuild with those #includes dropped
and it just worked. So yeah, it's better to think about config.h
explicitly and I suggest dropping it here. Updated patch attached.
> There's a lot of logic in the top level meson.build for selecting
> compiler and compiler options (and generating config.h).
That's only partially true. The project() declaration influences the
compiler selection and default options. These apply to both native and
cross compilers. The config.h is generated in libpam/include/meson.build
rather than the top level file from the configuration_data() object
cdata defined in the top level. Since it also has a number of HAVE_*
macros, it definitely is architecture-dependent.
> I suspect in most cases it will probably just work to use the same
> options for cross and native, but we've certainly come across cases
> where that's not true (for example the ftcbfs patch against pam was such
> a case).
Agreed.
> For example we explicitly find a compiler in the top level meson.build,
What you call explicit, I call implicit, as we merely tell it that this
is a c project with some default options. But then we also implicitly
find a native compiler that way!
> although only use that meson object for autoconf-style probing of the system.
> We never tell it to use that compiler for building executables.
> So there's a lot going on implicitly.
Exactly! Note that add_project_*() also has a native parameter that
defaults to false, so all of those add_project_*() in meson.build only
modify the regular compiler (cross compiler when doing a cross build)
and do not influence the native compiler (when they differ). In
principle, you might argue that try_cc_flags would also reasonably apply
to the native compiler and we should add:
add_project_arguments(
meson.get_compiler('c', native:
true).get_supported_arguments(try_cc_flags),
language: 'c',
native: true)
I appreciate your attention to detail. I concur that just adding
"native: true" to the one executable() may work now and produce subtle
breakage later. I argue that such breakage is limited to situations that
are broken due to the lack of "native: true" right now.
Helmut
