[Bf-committers] [22334] branches/blender2.5/blender: fix for build problem with audiospace and implicit declaration.

[GSR]

Hi,
nicholasbishop at gmail.com (2009-08-10 at 1418.34 -0400):
> I agree with his change; it seems like a bad idea to change all the
> build references for audio to include a reference to the *internal*
> header directory for audaspace. If the directory structure is at some
> point changed, it's better to have it just change in the external
> header (AUD_C-API.h). Also, the hardcoded path is still relative, so I
> don't see how it's any more hardcoded either way, you're still
> explicitly referencing a file.

The current tree is a chaos, you can find this:

intern/boolop/intern/BOP_Interface.cpp:31:#include "../../bsp/intern/BSP_CSGMesh_CFIterator.h"
intern/boolop/extern/BOP_Interface.h:31:#include "../../bsp/intern/BSP_CSGMesh.h"
intern/iksolver/test/ik_glut_test/intern/ChainDrawer.h:37:#	include "../intern/IK_QChain.h"
intern/iksolver/test/ik_glut_test/intern/ChainDrawer.h:38:#	include "../intern/IK_QSolver_Class.h"
intern/ghost/intern/GHOST_C-api.cpp:46:#include "intern/GHOST_Debug.h"
intern/ghost/intern/GHOST_C-api.cpp:51:#include "intern/GHOST_CallbackEventConsumer.h"
source/blender/render/intern/source/pipeline.c:65:#include "intern/openexr/openexr_multi.h"
source/blender/blenkernel/intern/node.c:71:#include "intern/CMP_util.h"	/* stupid include path... */
source/blender/blenkernel/intern/node.c:75:#include "intern/TEX_util.h"
source/blender/blenkernel/intern/image.c:47:#include "intern/openexr/openexr_multi.h"

Or other places where all the headers are at the same level, and thus
installing them works (via the *.h glob) even if they are not, for example:

./intern/memutil/MEM_Allocator.h
./intern/memutil/MEM_CacheLimiter.h
./intern/memutil/MEM_CacheLimiterC-Api.h
./intern/memutil/MEM_NonCopyable.h
./intern/memutil/MEM_RefCountPtr.h
./intern/memutil/MEM_RefCounted.h
./intern/memutil/MEM_RefCountedC-Api.h
./intern/memutil/MEM_SmartPtr.h

> It's not a huge deal either way, but I prefer not to alter a bunch of
> CMakeLists unnecessarily, so some consensus would be good :)

Yep, and then I could fix makefiles in one or the other direction,
because the source tree has examples for everything, with intern or
without intern, with hardcoded -I or ones that depend on variables. If
the way to go is to use in tree headers, then we can save a lot of
install operations.

GSR