Re: master fails to build/check

[Ladislav Michl]

On Fri, Jan 31, 2020 at 01:43:52PM -0800, Gary E. Miller wrote:
> Yo Ladislav!
> 
> On Fri, 31 Jan 2020 12:16:25 +0100
> Ladislav Michl <address@hidden> wrote:
> 
> > > Yeah, I remember those.  Those were alst cycle, I'm talking about
> > > this cycle.  
> > 
> > Sure, there's no way to fix things in the past, but those questions
> > are still valid.
> 
> Or not.
> 
> > > The sysroot patch makes no sense.  As used by scons, sysroot is a
> > > on the command line, yet you pull it from a non standard environment
> > > variable.  Can't do both.  Does not compute.  
> > 
> > I'm pulling it the same way as other options from the very same group
> > of options are pulled. See bellow.
> 
> Uh, no.  Looks similar, but different orderring.
> 
> > > If you want, let's discuss what the confusion is for the sysroot
> > > variable first.  My quick take is you just did not notice it
> > > belongs on the command line as an option.  
> > 
> > Fair enough. sysroot is listed in nonboolopts together with
> > gpsd_group, gpsd_user, max_clients, max_devices, (those seems not to
> > be used anywhere, btw)
> 
> Can you dispense with the digressions?  If you find unused variables
> please file issues on them, individually.
> 
> > and others like prefix, python_coverage,
> > target_python, etc. Values of these variables are read as
> > env['python_coverage']
> 
> A vast over simplification, nut useful to start.
> 
> > and my build script just does:
> 
> Oh, my.  What a mess...  But that is yet another discussion...

That mess is generated. gpsd choose to have all that options, so
lets feed it. We are always setting all those options, even with
default values, as it is easier to spot something has changed
after update.

> > sysroot=/home/ladis/src/C-ITS.Devices.O2.Firmware/platform-imx6/sysroot-target
> 
> Looks good.  Except for the email mangled it, and more, badly.

That's mailing list issue, I'm afraid.

> > as you can see, sysroot is
> > listed on the command line the same way as other options [*].
> 
> Yes.
> 
> > So now
> > that sysroot value is used like this (SConstruct line 642):
> 
> Or rather 646 in git head.  If you are going to use line numbers, please
> refer to git head.

I'm sorry, I forgot to wipe local patch.

> > # while
> > this makes perfect sense if env['target']: for (name, toolname) in
> > devenv: env[name] = env['target'] + '-' + toolname # why this?
> 
> Uh, lost me.
> 
> > if env['sysroot']:
> >     env.MergeFlags({"CFLAGS": ["--sysroot=%s" % env['sysroot']]})
> >     env.MergeFlags({"LINKFLAGS": ["--sysroot=%s" % env['sysroot']]})
> 
> Looks correct.  sysroot just passed on the the C compiler and linker.
> 
> > Every single cross-compiler I've worked with so far is aware of it's
> > own headers and passing --sysroot= here makes it blind.
> 
> So don't use sysroot.  Other people need it.  Your choice.

Remember? I was asking _how_ do people cross-compile.

> > - if SConstruct uses sysroot as a toolchain sysroot it is the only
> >   tool doing so this way and question is why it is doing so.
> 
> Because some users insisted.  Find a cross-compile user to ask, or
> look in the git log and email archive for why.

Didn't find anwer in mail archive nor git. Also yocto and buildroot
are patching gpsd to be able to crosscompile. And reading your
answers they will continue doing so ;-)

> >   However it will work if:
> >   - all libraries gpsd depends on are installed into toolchains
> > sysroot. This pollutes toolchain installation.
> 
> And yet, quite common.

Common? I remember decades ago it was quite more common than today and
I'm glad those times are away. Single toolchain can be used to compile
dozens different projects, so putting all that different garbage into
toolchains sysroot is not an option. But point taken, for those people
still doing so, it is "usefull".

> If they are NOT installed there, then how is gpsd supposed to find them?

They can be installed anywhere as long as we have a way to tell gpsd.
And it seems pkg-config and cross-python do their job here (read: it
works for me)

> They are certainly NOT the ones the host OS is using.

Please avoid stating obvious, makes emails shorter. Thank you.

> >   - toolchain sysroot is installed into staging area and then all
> >     libraries are installed here. Unusual.
> 
> gpsd does not use any staging area.

Not talking about gpsd. Talking about root directory all libraries
gpsd depends on are installed. See bellow

> > - if SConstruct is using sysroot as all other packages, passing
> > --sysroot to toolchain is just wrong.
> 
> Hmm, so you are saying sysroot is not sysroot?  That makes no sense.
> It is a gcc and ld option that you may use, or not.  If you don't want
> it passed to gcc and ld, then don't call it sysroot.

Toolchain sysroot is definitely something else than autotools sysroot.
I just couldn't believe there is a project that needs to set
toolchains sysroot. See later.

> > I would deeply appreciate if someone could explain me how is this
> > SConstruct thing supposed to work.
> 
> Just like make and autoconfuse it takes a whole lot of work to understand.

Yes, and because those are pretty common, that work was already invested.

> Maybe better to just ask for what you need, and let those that understand
> how gpsd builds come up with some solutions.
> 
> So, what do you need?

I need to be able to crosscompile gpsd. I certainly do not want to install
anything to toolchains sysroot. And I'd like to be able to do it as easily
as with autotools or meson.

> > [*] See here:
> > https://git.pengutronix.de/cgit/ptxdist/tree/rules/gpsd.make#n55 and
> > as PTXdist developers are trying to minimize out of tree patches and
> > upstream them, I hope we can find solution.
> 
> That is a makefile. gpsd does not use makefiles.  And an ugly one at
> that.  A perfect example of why gpsd is (slowly) getting rid of compile
> time options.  I'll leave that mess to you.

I'm sorry I bothered you with an example how scons gets called. It is
nice of you (as a gpsd developer) leaving all that mess to me. Just
rememeber - that mess originates in gpsd project.

> OTOH, if you have suggestions for more/better/different scons options
> then please ask.  One at a time.

I think I can live with gpsd as it is. All cross build systems supports
patching instantly, just to handle situations as this one.

> After you explain what yuo think you need that is like sysroot but is
> not sysroot.

In my universe, when cross-compiling packages with multiple dependencies
or even entire operating system images, sysroot is a directory used as
prefix while mimicking the installation layout of a normal running system.

So, sane cross aware package is pointed to this directory, it is
instructed which toolchain to use and a magic happends.

        ladis
I was just interested how to do the same with gpsd.