IMO, if new functions are going to be introduced, then put them into a
namespace. ... "ASSERT" is who-knows-what. "MYNEWT_ASSERT" is clearly part
of the mynewt OS.

That said, it is ugly, so how about finding a PREFIX that can be set all
our custom symbols aside, and point people into the right direction to look
them up?

"MN_" is an obvious candidate.

Are there others, that might play on the "minute" or "mynewt" words?

Cheers,
-g


On Tue, Oct 27, 2015 at 9:38 AM, will sanfilippo <[email protected]> wrote:

> Regarding assert() and assert_debug(). Where would you put the dir “sys”?
> Why not put the definitions in an os include dir? Is that due to
> dependencies you would not want (i.e. os would need console, or something
> like that)? Or that you dont feel like assert belongs in the os?
>
> About the names: I think someone was mentioning that assert normally gets
> defined out if you define NDEBUG. Is that true? If that is the case,
> shouldnt we keep that paradigm? I know we discussed this a bit but I cant
> recall what we decided :-)
>
> Will
>
>
> > On Oct 26, 2015, at 5:36 PM, marko kiiskila <[email protected]> wrote:
> >
> >>
> >> On Oct 26, 2015, at 5:08 PM, Christopher Collins <[email protected]>
> wrote:
> >>
> >> On Mon, Oct 26, 2015 at 03:35:12PM -0700, marko kiiskila wrote:
> >>> Hi,
> >>
> >> [...]
> >>
> >>> And 2nd (related) topic:
> >>> At the moment there is libs/console/full and libs/console/stub.
> >>> What kind of mechanism should we have for picking between
> >>> these two implementation? What I’d need is a way for a builder
> >>> of project to pick between these, and all eggs in the project
> >>> to have include the header file for the right implementation.
> >>>
> >>> But I also want to be able to specify within egg definition that
> >>> the egg will make calls to console_printf(). Egg itself does not
> >>> care which one of the implementations gets used.
> >>>
> >>> Is there a way to do this kind of thing yet?
> >>
> >> The newt tool supports the concept of "capabilities" which can address
> >> this requirement.
> > ...
> >> All that said, the capabilities feature isn't actually fully implemented
> >> yet; the above is just how I might expect it to work once it is done :).
> >>
> >> Here are a few more questions that I think need to be answered:
> >>
> >>   * How does the "peripheral" egg include the appropriate console
> >>     header files?  Even if both console eggs have identically named
> >>     header files, newt needs to arrange for the appropriate include
> >>     directory to be passed to the compiler.
> >>
> >>   * What is an easy way to switch between the debug and full
> >>     implementations.  The user should not need to modify the
> >>     myproject.yml file to do this.  Perhaps the "identities" feature
> >>     can be used here.
> >>
> >
> > Thanks, this sounds like a thing that matches my requirement.
> > I’ll have to start filling in these blanks in newt tool then.
> >
> > I think I’ll treat a dependency that comes in a form of capability
> > requirement the same way as I’d treat normal dependency:
> > once an egg is found which implements the capability, it’s include
> > path is passed to compiler.
> >
> > I won’t address the identity thing with this work, but that sounds
> > useful. Depending on whether you’re building a debug version of your
> > project or not, you could pick whether you get console output.
>
>

Reply via email to