> we use autotools and check to add or not add cflags or ldflags should be
> there.
> I think in that case it's better to make such check in that file:
> ./platform/linux-generic/m4/configure.m4
> 
> So check should be code compilation with libatomic and without and set or
> not set it in ldflags.
> 
> 
> To check there are 2 ways:
> 1. localy
> https://git.linaro.org/lng/check-odp.git/
> GIT_BRANCH=master PATCH_DIR=/opt/Linaro/odp3.git IGNORE_BASE=1 CLEANUP=0
> ENABLE_DPDK_PKTIO=0 ENABLE_IPC_PKTIO=0 DISTCHECK=1
> GIT_URL=/opt/Linaro/odp3.git ./build.sh

This check script doesn't appear to be working properly for me, but
regardless, since "__atomic_compare_exchange_n" is used within the general
codebase (e.g. in platform/linux-generic/pktio/ring.c) this patch shouldn't
introduce any changes to the primary configure files.

Since you are able to recreate the problem, have presumably verified a way of
resolving it, and are far more versed in the project infrastructure than I,
would it be at all possible for you to advise on what example-specific
configuration changes might be necessary here?

> > As for the variable declarations, again this was an issue I attempted to
> > get
> > to the meat of previously. Are we talking about variables within nested
> > blocks, outside these blocks, in long functions, in short functions? It's
> > hard to address the issue here when I'm not entirely sure which part of it
> > you would like addressing. As indicated before, the longer functions like
> > main and add_fraglist_to_fraglist benefit greatly from splitting
> > declarations
> > throughout their bodies. I can squish all the declarations together, making
> > the code unreadable, if that's what you would like for it to be merged, but
> > I'm assuming that this wouldn't be a desirable outcome either. If you could
> > respond to the relevant points I've raised below, allowing me to resolve
> > some
> > of these issues, it would be greatly appreciated.
> >
> 
> ok, I will run over patch to comment on places which I think needs to be
> changed.

Great, thanks. Please do take into account readability in your suggestions,
though, as I plan on implementing them under the assumption that you have
made all appropriate style consideration as appropriate for the project
following our extensive discussions in this area.

Reply via email to