Re: master fails to build/check

[Ladislav Michl]

Hello Garry,

On Fri, Jan 31, 2020 at 04:40:48PM -0800, Gary E. Miller wrote:
> Yo Ladislav!
> 
> On Sat, 1 Feb 2020 01:11:59 +0100
> Ladislav Michl <address@hidden> wrote:
> 
> > > > > > and all libraries gpsd
> > > > > > depends on are discoverable using pkg-config.    
> > > > > 
> > > > > Not even close.  Forget you ever thought that.    
> > > > 
> > > > I will not, sorry.  
> > > 
> > > Then please keep your thoughts that do not match facts private.  
> > 
> > I can only wish you'll take this line as a fact:
> > arm-v7a-linux-gnueabihf-gcc -o pseudonmea.o -c -pthread -Wall
> > -Wcast-align -Wextra -Wimplicit-fallthrough -Wmissing-declarations
> > -Wmissing-prototypes -Wno-missing-field-initializers
> > -Wno-uninitialized -Wpointer-arith -Wreturn-type -Wstrict-prototypes
> > -Wvla -O2 -pthread
> > -I/home/ladis/src/C-ITS.Devices.O2.Firmware/platform-imx6/sysroot-target/usr/include/dbus-1.0
> > -I/home/ladis/src/C-ITS.Devices.O2.Firmware/platform-imx6/sysroot-target/usr/lib/dbus-1.0/include
> > -I/home/ladis/src/C-ITS.Devices.O2.Firmware/platform-imx6/sysroot-target/usr/include/libusb-1.0
> > pseudonmea.c It comes from cross-compiling gpsd and as you can see,
> > those dbus-1.0 and libusb-1.0 include paths were discovered using
> > pkg-config.
> 
> I know pkg-config sometimes works, for some people.
> That says nothing about pkg-config working for all people all the time.

Seems we are in "Pot, kettle, black" swamp again...

> I'm saying, as fact, that pkg-config does not work for all people all the
> time.  Nice to have, do not count on it.  Works for you is nice for you.
> Works for everyone is a good patch.

I'm obviously unable to fix all people problems for eternity. I'm just
stating I do not need to use gpsd's sysroot as long as pkg-config does
the job for me.

> > > The code you mentioned was gated by env['systemd'].  Maybe
> > > instead "env['systemd'] and env['target']"?  
> > 
> > And what if I still do want to install udev rules and systemd units?
> > To the sysroot^H^H^H^H^H^H^H DESTDIR.
> 
> I saw nothing in your patch about install dir.  Feel free to open up
> an email thread on that SINGLE issue.  So we can stop bouncing around,
> settling on nothing.

That's unevitable consequence of using sysroot. Now, once I know, I
should stay away from sysroot, I need to be able to install udev rules
and systemd units to the staging area, elsewhere known as sysroot.

> > > > Or there are people out there wanting tickle host systemd while
> > > > cross-compiling?  
> > > 
> > > Seriously?  Seems to me you are either buliding gpsd for the present
> > > hot, or for a target host, but not both at the same time.  What is
> > > the use case for that?  
> > 
> > Above, of course, was not meant seriously at all.
> 
> Irony does not work well in emails...  See Poe's Law.
> 
> > Check for 'target' is already used when skipping check for
> > sizeof(time_t), so let's be consistent.
> 
> Yes, but the patch was not exactly that.

Care to explain how it should be modified to be _exactly_ that?
Also see 777cb3737ae8 ("do not interact with systemctl when
cross-compiling") for rationale. The rationale is right, but
test should depend on target rather than sysroot.

> > Also, technically, --sysroot= can be passed even to native toolchain.
> 
> Of course.
> 
> > > You gotta have some way to separate out the stuff used by the host,
> > > from stuff that is for the target.  There are other ways that scons
> > > also uses.  Use what works for you.  
> > 
> > I have to admit current git is much better in terms of
> > cross-compilation than 3.19 was.
> 
> And a lot more SConstruct work to be done this cycle.
> 
> > > So, instead of spending time bike shedding, do you have a real
> > > problem here that needs solving?  
> > 
> > None of problems I have are "real".
> 
> Uh?  I prefer not to waste time on fantasy issues.  If it is not real to
> you, why are you bringing it up?

I call problems I'm unable to solve or to solve them using enormous
efford real problems. I just though we could come to the point where
gpsd would be fully cross-compilable without external patches before
release.

Also so far noone cared (not counting you as you clearly stated you
are not cross compiling), so it seems it is not a real problem other
people have.

> > All of them can be solved more or
> > less elegant way. I searched archives and found only rants and
> > questions, but nothing even remotely describing people's cross-build
> > environment.
> 
> Yup.  Which is why I keep asking you to decribe yours so that cycle
> can end here and now.

I have already pointed you to my cross-build environment and you called
that mess. So I guess we reached dead end.

> > So, there is nothing to solve after all as those who asked before me
> > either found a way and kept it private, or keep patching gpsd [*] or
> > build only subset of options so they do not run into troubles.
> 
> Hmm, those all seem like solutions to me?  Please pick one.
> 
> > [*]
> > https://github.com/openembedded/meta-openembedded/blob/master/meta-oe/recipes-navigation/gpsd/gpsd/0001-SConstruct-prefix-includepy-with-sysroot-and-drop-sy.patch
> 
> Some good ideas in there, some bad.  Certainly breaks normal builds.
> 
> Does that work for you?

I solved it similar way before, but this one should work for me as well.
Meanwhile better solution was developed.

> > To be fair, this patch could be omited and situation solved with
> > cross-python wrapper.
> 
> In the spirit you ask for, of providing answers for future cross-dev
> people, care to elaborate?

I already set those answers into patchset, but last time it came to
lines mangling problem, you answered PEBKAC. And as I'm sending patches
inline and lines get mangled here, we reached yet another dead end.

Best regards,
        ladis