|
| From: | Felix Ruess |
| Subject: | Re: [Paparazzi-devel] Dependency problem |
| Date: | Tue, 29 Oct 2013 21:00:29 +0100 |
Or something like the last solution mentioned here: http://scottmcpeak.com/autodepend/autodepend.htmlOn Tue, Oct 29, 2013 at 8:47 PM, Felix Ruess <address@hidden> wrote:Not entirely sure, but there is probably a way to use the -MT option together with .d dependency files:On Tue, Oct 29, 2013 at 8:30 PM, Ben Laurie <address@hidden> wrote:
On 29 October 2013 17:51, Ben Laurie <address@hidden> wrote:OK. That's not the problem.
> On 29 October 2013 17:36, Felix Ruess <address@hidden> wrote:
>>
>>
>>
>> On Tue, Oct 29, 2013 at 6:14 PM, Ben Laurie <address@hidden> wrote:
>>>
>>> On 29 October 2013 14:09, Felix Ruess <address@hidden> wrote:
>>> > Why wouldn't it be legal?
>>> > The C preprocessor substitutes GPS_TYPE_H by the appropriate header file
>>> > and
>>> > then it is included as usual.
>>>
>>> Sure, I get it, I just find it mildly surprising.
>>
>>
>> Well, we want to be able to simply include "subsystems/gps.h" in other parts
>> of the code and not care about which GPS implementation is actually used.
>> This makes that possible.
>>
>>> But I find it even more surprising that it doesn't appear to be picked
>>> up by dependency generation.
>>
>>
>> Would be great if you could look into this, I'm a bit short on time right
>> now.
>
> Yeah, I'm going to.
>
>> Hint: maybe we should only use the -M flag of gcc instead of -MM
The problem is that gcc -MM (or -M or anything else) strips the
directory off the front. You put it back as $(OBJDIR), using sed, but
that's not right - for example, gps_ubx.o needs to be in
$(OBJDIR)/subsystems/gps.
AFAICS, there's no way to fix this easily. I think the only answer is
a script that generates dependencies a file at a time and puts the
subdirectories back in. I'd normally write such a thing in Perl or
Python, but I'm betting you don't want to add those as dependencies.
And I don't know how to write ML...
Suggestions?
>>
>>>
>>> > As mentioned in a previous mail:
>>> > Dependency generation is specified in the appropriate Makefile, e.g. for
>>> > the
>>> > ARDrone in conf/Makefile.omap Line185
>>>
>>> Aha. Thanks.
>>>
>>> >
>>> >
>>> > On Tue, Oct 29, 2013 at 2:33 PM, Ben Laurie <address@hidden> wrote:
>>> >>
>>> >> On 29 October 2013 12:33, Felix Ruess <address@hidden> wrote:
>>> >> > I think that is because gps_ubx.h is only "transitively" included via
>>> >> > gps.h
>>> >> > using #include GPS_TYPE_H
>>> >>
>>> >> Arg!
>>> >>
>>> >> I didn't even know it was legal to do includes like this. But
>>> >> surprised they're not discovered. I couldn't track down where/how
>>> >> dependencies are handled - any hints?
>>> >>
>>> >> >
>>> >> >
>>> >> > On Tue, Oct 29, 2013 at 1:18 PM, Ben Laurie <address@hidden> wrote:
>>> >> >>
>>> >> >> On 29 October 2013 12:03, Christophe De Wagter <address@hidden>
>>> >> >> wrote:
>>> >> >> > paparazzi (or actually make) tracks dependencies quite well,
>>> >> >> > however,
>>> >> >> > make
>>> >> >> > does not understand the xml-configuration well.
>>> >> >>
>>> >> >> Hmm. When I edit gps_ubx.h and do:
>>> >> >>
>>> >> >> % make AIRCRAFT=ardrone2_raw ap.compile
>>> >> >>
>>> >> >> it doesn't recompile anything. It should.
>>> >> >>
>>> >> >> >
>>> >> >> > - So if for instance you change your xml and add a <define ... >
>>> >> >> > somewhere,
>>> >> >> > make does not understand which control or driver files are
>>> >> >> > affected.
>>> >> >> > You
>>> >> >> > then MUST clean before recompile.
>>> >> >> > - Even worse: if you change the board file to another arch in the
>>> >> >> > middle of
>>> >> >> > some work, it will only rebuild the changed c files so you can
>>> >> >> > have
>>> >> >> > object
>>> >> >> > files compiled with different architectures being linked (which
>>> >> >> > does
>>> >> >> > fortunately not work)
>>> >> >> > - And if you change a module.xml, the build system does not
>>> >> >> > necessarly
>>> >> >> > know
>>> >> >> > it should recompile (whjile for subsystems it does know as it is
>>> >> >> > makefile)
>>> >> >> >
>>> >> >> > Our rules of thumb:
>>> >> >> > - make clean anytime you need to be really sure
>>> >> >> > - certainly clean after every xml change
>>> >> >> >
>>> >> >> > PS: thanks for the pull request.
>>> >> >> >
>>> >> >> > -Christophe
>>> >> >> >
>>> >> >> >
>>> >> >> > On Tue, Oct 29, 2013 at 12:01 PM, Ben Laurie <address@hidden>
>>> >> >> > wrote:
>>> >> >> >>
>>> >> >> >> On 28 October 2013 12:50, Felix Ruess <address@hidden>
>>> >> >> >> wrote:
>>> >> >> >> > Hi Ben,
>>> >> >> >> >
>>> >> >> >> > seems that this is because the gps_ubx_ucenter.c file is
>>> >> >> >> > INCLUDED
>>> >> >> >> > in
>>> >> >> >> > subsystems/gps/gps_ubx.c Line 271 rather than being added as a
>>> >> >> >> > normal
>>> >> >> >> > source
>>> >> >> >> > file.
>>> >> >> >> > While this was probably easier to implement (to allow access to
>>> >> >> >> > ubx
>>> >> >> >> > internals to the ucenter module) it's not very nice.
>>> >> >> >> > Christophe may have more details as he wrote the
>>> >> >> >> > gps_ubx_ucenter
>>> >> >> >> > module.
>>> >> >> >>
>>> >> >> >> I am sending a pull request that fixes this.
>>> >> >> >>
>>> >> >> >> In general, though, it seems paparazzi doesn't track
>>> >> >> >> dependencies.
>>> >> >> >> Am
>>> >> >> >> I right, or am I missing something?
>>> >> >> >>
>>> >> >> >> >
>>> >> >> >> > Cheers, Felix
>>> >> >> >> >
>>> >> >> >> >
>>> >> >> >> > On Sat, Oct 26, 2013 at 7:55 PM, Ben Laurie <address@hidden>
>>> >> >> >> > wrote:
>>> >> >> >> >>
>>> >> >> >> >> If I modify gps_ubx_center.c, then rebuild ardrone2_raw, it
>>> >> >> >> >> does
>>> >> >> >> >> not
>>> >> >> >> >> recompile that file...
>>> >> >> >> >>
>>> >> >> >> >> _______________________________________________
>>> >> >> >> >> Paparazzi-devel mailing list
>>> >> >> >> >> address@hidden
>>> >> >> >> >> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>>> >> >> >> >
>>> >> >> >> >
>>> >> >> >> >
>>> >> >> >> > _______________________________________________
>>> >> >> >> > Paparazzi-devel mailing list
>>> >> >> >> > address@hidden
>>> >> >> >> > https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>>> >> >> >> >
>>> >> >> >>
>>> >> >> >> _______________________________________________
>>> >> >> >> Paparazzi-devel mailing list
>>> >> >> >> address@hidden
>>> >> >> >> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>>> >> >> >
>>> >> >> >
>>> >> >> >
>>> >> >> > _______________________________________________
>>> >> >> > Paparazzi-devel mailing list
>>> >> >> > address@hidden
>>> >> >> > https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>>> >> >> >
>>> >> >>
>>> >> >> _______________________________________________
>>> >> >> Paparazzi-devel mailing list
>>> >> >> address@hidden
>>> >> >> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>>> >> >
>>> >> >
>>> >> >
>>> >> > _______________________________________________
>>> >> > Paparazzi-devel mailing list
>>> >> > address@hidden
>>> >> > https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>>> >> >
>>> >>
>>> >> _______________________________________________
>>> >> Paparazzi-devel mailing list
>>> >> address@hidden
>>> >> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > Paparazzi-devel mailing list
>>> > address@hidden
>>> > https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>>> >
>>>
>>> _______________________________________________
>>> Paparazzi-devel mailing list
>>> address@hidden
>>> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>>
>>
>>
>> _______________________________________________
>> Paparazzi-devel mailing list
>> address@hidden
>> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>>
_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
| [Prev in Thread] | Current Thread | [Next in Thread] |