rtems-libbsd

Chris Johns chrisj at rtems.org
Tue Jun 23 06:41:24 UTC 2015


On 23/06/2015 4:31 pm, Sebastian Huber wrote:
> 
> 
> On 23/06/15 02:03, Gene Smith wrote:
>>>   F_MEDIA_H=1 -DHAVE_SYS_IOCCOM_H=1 -DNEED_YYPARSE_WRAPPER=1
>>> -Dyylval=pcap_lval -c freebsd/contrib/libpcap/scanner.c -o
>>> freebsd/contrib/libpcap/scanner.o'
>>> Makefile:114: recipe for target 'freebsd/contrib/libpcap/scanner.o'
>>> failed
>>> make: *** [freebsd/contrib/libpcap/scanner.o] Error 1
>>>
>>
>> There are a bunch of problems with the Makefile since tcpdump was
>> added and I suggested some fixes but, since it is deprecated, it won't
>> be fixed. See this posting for the manual fixes you can make:
>> https://lists.rtems.org/pipermail/users/2015-June/029079.html 
> 
> In case nobody wants to fix the Makefile, then we should remove it.
> 

I do not care if it stays or goes and I suppose I should fix it because
I broke it if it stays. Once it is decided let me know. It has been a
low priority for me.

I suspect it would take a while for someone new to figure out the python
and understand what is happening. There is a bit of indirection
happening in the generators now.

The issue with the Makefile is the complexity is starting to increase.
For example the tcpdump command has added private includes to the build
and so we should start to consider the global list we have. The end
result is the command lines in the Makefile for each file rise in size
and complexity. The tcpdump command forced this because it uses an
include path trick to pick up a private specific config.h. That header
could not leak to other parts of the build.

My longer term concern is a change appears that is just too hard to do
in the Makefile.

Chris



More information about the users mailing list