There is already so much output generated during building that it slows a
developer down to go through the output to determine what things must be paid
attention to, what things can be ignored and what things are simply
informational. My vote is for a solution that doesn't add to that burden.
Most of the output is just distracting, but then on the other hand one does
want to get some sense that the build is making progress. It would be really
nice, I think, to get just one over-printed line that shows what directory is
being worked on and that newlines are generated only by error, warning, and
perhaps informational messages.
Perhaps a possibility is to introduce --enable-mm on the configure line and
then to print the compile-time warning only when there is a disagreement
between the flag and the ability, i.e., --enable-mm is present, but mm support
isn't, and --enable-mm is not present, but mm support is. In the "normal" case
(--enable-mm is present and mm is supported, and --enable-mm is not present and
mm support isn't) the build system would stay quiet.
Cheers,
Ric
________________________________________
From: rtems-devel-boun...@rtems.org [rtems-devel-boun...@rtems.org] On Behalf
Of Gedare Bloom [ged...@rtems.org]
Sent: Wednesday, July 24, 2013 9:50 AM
To: Rempel, Cynthia
Cc: rtems-devel@rtems.org
Subject: Re: [PATCH 1/2] libmm score and stubs
On Wed, Jul 24, 2013 at 12:43 PM, Rempel, Cynthia
<cynt6...@vandals.uidaho.edu> wrote:
>>________________________________________
>>From: ged...@gwmail.gwu.edu [ged...@gwmail.gwu.edu] on behalf of Gedare Bloom
>>[ged...@rtems.org]
>>Sent: Wednesday, July 24, 2013 9:19 AM
>>To: Rempel, Cynthia
>>Cc: Hesham AL-Matary; rtems-devel@rtems.org
>>Subject: Re: [PATCH 1/2] libmm score and stubs
>>
>>On Wed, Jul 24, 2013 at 11:02 AM, Rempel, Cynthia
>><cynt6...@vandals.uidaho.edu> wrote:
>>> Hi Hesham,
>>>
>>> Thanks for doing the stubs :)
>>> Could you pull all the implementation specific parts of mm.h and mm.inl
>>> into a header called mmimpl.h ?
>>> It would then match the header-style score is heading towards...
>>> If the no_memorymanagement.c is for devices without mm support, could you
>>> have the functions print out a "stub warning/error" message? That way the
>>> user knows not to rely on memory management...
>>>
>>I don't think we should have the stubs do anything in the normal case.
> Why?
We should not add print statements to kernel code. Some users may
prefer to leave the stubs in place despite the lack of functionality.
Maybe you mean a compile-time warning, which would be fine to add.
>>We could add something when RTEMS_DEBUG is enabled.
>
>
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
