On Thu, Oct 03, 2019 at 12:08:30PM +0200, David Marchand wrote:
> On Thu, Oct 3, 2019 at 11:21 AM Bruce Richardson
> <bruce.richard...@intel.com> wrote:
> >
> > On Wed, Oct 02, 2019 at 06:55:47PM +0200, David Marchand wrote:
> > > Same idea than overriding PATH and PKG_CONFIG_PATH, it can be quite
> > > useful to override compilation flags like CFLAGS, CPPFLAGS and LDFLAGS
> > > for cross compilation or libraries that won't provide a pkg-config file.
> > >
> > > Fixes: 272236741258 ("devtools: load target-specific compilation
> > > environment")
> > >
> > > Signed-off-by: David Marchand <david.march...@redhat.com>
> > > ---
> >
> > No strong objection to this change, but for meson the better way to handle
> > this may be to put these flags into the cross-file used for the build. By
> > explicitly passing CFLAGS etc. to the build, I'm not sure what the
> > behaviour is with regards to passing those flags to cross-built vs
> > native-built components. For a cross-compile, not all CFLAGS should be
> > passed to the build of pmdinfogen, for instance.
>
> Ok, I see.
>
> Then the only usecase would be for locally built libraries that meson
> can't find by itself.
> A bit hackish too.
>
> Mm, is there a way to tell meson "library X (CFLAGS, LDFLAGS) is (xx, yy)" ?
> I could write some local .pc files and override PKG_CONFIG_PATH...
> Any better idea ?
>
If the scheme here using CFLAGS/LDFLAGS works just go with it for now.
Ideally for cross compiles, we could consider taking the stored
cross-compile files and copying them to /tmp and then adding the additional
flags there. However, for just passing flags to help find library X or Y,
its probably not worth doing, so let's keep it simple until we need
something more powerful. I was just pointing out that this could cause
issues in the future if we do start using it for something more fancy...
