I have no idea why this error happens, but it does not seem worth the effort to investigate further, so I'm just reverting the previous change to this file.
I am not sure why the definition of NULL was removed; it might have been by mistake, but in any case it broke code like this:
img = PNMImage(w, h, color_space=CS_srgb)
since it would not understand the default value (NULL) for the argument preceding color_space.
This distinction allows us to better support Python 3, since it will raise exceptions when trying to put arbitrary binary data in a str object.
This also adds some convenience functions for efficiently initializing a Datagram or PTA_uchar from a vector_uchar.
This is designed to sanity-check the buildsystem, ensuring that the
expected BUILDING_ macros are defined at the expected time. It
also helps catch cases where the wrong BUILDING_/EXPCL_ macros
are used.
The GCC documentation states that, as of GCC 2.7.2, these aren't
necessary for proper program behavior. The documentation further
discourages their use because they don't suppress unnecessary code
duplication.
The Panda codebase these days uses "extern template class" instead,
which tells the compiler not to perform implicit template expansion
because an explicit template expansion is available for linking
elsewhere in the program. This is a more compiler-neutral way of
achieving the same thing as '#pragma interface', making
'#pragma interface' not only redundant, it could also mask problems
in the "extern template class" machinery.
As of f69354d9fa, this is just always
expected on all platforms. If it's not defined,
TemplateClass<X>::_type_handle won't link correctly with some compilers
(e.g. Clang) and the lack of 'extern template class' will result in
duplicated code in any case. In short, turning it off causes problems.
makepanda also always turns this on, so it doesn't represent any
optional feature or autodetected platform-specific behavior anyway.
This will help us catch cases wherein we inadvertently create a circular dependency between component libraries. Right now it only checks inheritance and typedefs, but this can be expanded in the future.
Also, sorts the module initialization by dependency topology. This isn't very important right now, but having this guarantee might help when refactoring module initialization in the future.
Typedefs are evidently always considered "fully defined", so we need to add another condition to the database merging code to prefer the type that is marked "global" when merging two types.
The binary path we get from /proc/self/exe isn't very useful; the path to the .apk is barely more useful but it still doesn't make a whole lot of sense. It might make more sense to set it to the path of the native .so that is being loaded by NativeActivity.
Sam Edwards
rdb