gpsd-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-dev] gpsd_config.h in release tarballs can break rebuild


From: Fred Wright
Subject: Re: [gpsd-dev] gpsd_config.h in release tarballs can break rebuild
Date: Wed, 18 Jan 2017 23:56:53 -0800 (PST)

On Thu, 19 Jan 2017, Sanjeev Gupta wrote:
> On Thu, Jan 19, 2017 at 12:08 PM, Fred Wright <address@hidden> wrote:
>
> > There is something a bit fishy here, however.  It's not clear to me why it
> > was ever necessary to include gpsd_config.h in generated_sources just for
> > cleaning purposes.  While it is true that SCons's autogenerated cleaning
> > list can be fragile with respect to files whose creation can depend on
> > options, I don't see why that ever would have been a problem for the
> > unconditionally generated gpsd_config.h.  And indeed, if I check out the
> > code immediately before Sanjeev's fix, then build and clean, I don't see a
> > leftover gpsd_config.h (though I do see a leftover libQgpsmm.dylib).
> > Meanwhile, generated_sources is no longer added to the explicit clean list
> > in recent versions, anyway (I think as part of some cleanup of the clean
> > stuff I did a while back).
> >
>
> I confess, I am the Sanjeev here :-)

Yes, I was hoping you'd chime in. :-)

> Please see:
> http://lists.nongnu.org/archive/html/gpsd-dev/2015-04/msg00015.html
> I identified a problem wrongly, thinking that scons was not cleaning well.
>
> Later in the thread, after others had reproduced the error, and the patch
> was in, I reported that the real problem may be different:
> http://lists.nongnu.org/archive/html/gpsd-dev/2015-04/msg00022.html
>
> This is to give context to why it was patched.

Ah, yes, the corrupted SCons database problem - I've been burned by it
before, but it's not something that can be fixed in SConstruct. :-)

In my case, I needed a patched version of SConstruct for testing, so I'd
put one in another directory, and used "scons -f" to reference it.  What I
hadn't realized at the time is that SCons keeps its temporaries in the
same directory as the SConstruct file, *not* necessarily the current
directory.  So the corrupted database survived the usual "rm -rf .scon*"
and had me tearing my hair out over the weird build failures.

BTW, I think the "sconsclean" target is rather pointless, since it's
impossible to fully remove all SCons temporaries from within SCons itself.
It would be better to make it a shell script.  Though if you're working in
a git repo, then "git clean -dxf" works quite nicely. :-)

Fred Wright



reply via email to

[Prev in Thread] Current Thread [Next in Thread]