On 02/08/17 14:03, Joe Savage wrote: >> 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?
ok. looking into that. > >>> 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. > ok.
