Hey John, On 3/29/2019 9:44 AM, John Beard wrote: > Hi Wayne, > > Duh, it's a Boost version thing, and I ran it though different > platforms *except* the old-Boost one. Face, meet palm. > > Funnily enough, as this header is often included first, this one > *should* be immune to ordering issues. > > Also, I sent a proposal for a modification to the Coding Policy > document this week, which expands on that header deps point: it notes > that by making implementations include their "own" headers first in > the list, all headers that are in a .cpp/.h pair are forced to be > immune to ordering problems.
I don't know if I want to force this even though I think it's a good idea. So few of the source files in KiCad adhere to this that it would confuse new developers. However, devs should be aware of the issue. > > It doesn't help for standalone utils headers though, unless, like this > one, they just happen to also come first in the list. > > Cheers, > > John > > On Fri, Mar 29, 2019 at 1:01 PM Wayne Stambaugh <[email protected]> wrote: >> >> Hey John, >> >> Thanks for the quick fix. It could be due to header ordering in the >> source files. I generally try to compile the headers separately to >> catch issues like this. There is helpful instructions in the coding >> policy on how to do this. Given the number of headers included in the >> KiCad source files, it's easy to overlook this. >> >> Cheers, >> >> Wayne >> >> On 3/29/19 8:53 AM, John Beard wrote: >>> Hi Wayne, >>> >>> Thanks for the heads up. I've pushed a fix to both branches. I'm not >>> sure why that ever worked silently on Linux GCC/Msys2 GCC/MSVC, but >>> using std:: is certainly correct. Perhaps a header has a sneaky type >>> alias somewhere. >>> >>> Cheers, >>> >>> John >>> >>> On Fri, Mar 29, 2019 at 12:30 PM Wayne Stambaugh <[email protected]> >>> wrote: >>>> >>>> Commit ad76ebd8 broke builds when compiling with clang. >>>> >>>> home/wayne/src/kicad-trunk/qa/unit_test_utils/include/unit_test_utils/unit_test_utils.h:121:24: >>>> error: >>>> unknown type name 'nullptr_t'; did you mean 'std::nullptr_t'? >>>> struct print_log_value<nullptr_t> >>>> ^~~~~~~~~ >>>> std::nullptr_t >>>> /usr/bin/../lib/gcc/x86_64-linux-gnu/8/../../../../include/x86_64-linux-gnu/c++/8/bits/c++config.h:242:29: >>>> note: >>>> 'std::nullptr_t' declared here >>>> typedef decltype(nullptr) nullptr_t; >>>> ^ >>>> In file included from >>>> /home/wayne/src/kicad-trunk/qa/common/test_array_options.cpp:29: >>>> In file included from >>>> /home/wayne/src/kicad-trunk/qa/unit_test_utils/include/unit_test_utils/geometry.h:28: >>>> >>>> _______________________________________________ >>>> Mailing list: https://launchpad.net/~kicad-developers >>>> Post to : [email protected] >>>> Unsubscribe : https://launchpad.net/~kicad-developers >>>> More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
