Yafray directory structure
This document outlines the proposed file and directory layout for the Yafray redesign. We'll attempt to list all the requirements for the directory structure, and then a solution that fulfills all those requirements.
- Compile without user intervention on at least
- Mac OSX
- Have a safe structure to allow parts of yafray to be used as libraries in 3rd party products e.g. Blender, Aztec with minimal risk of namespace or include file pollution.
- Have a public set of header files and libraries that are easy to redistribute independant of the implemenation source code to allow shader authors to easily use the yafray core to extend yafray.
- Compile cleanly without polluting the source direcories with files
- Be able to produce a variety of independant builds, such as debug vs release versions, or any other permutation.
Implications of the requirements
Compile on Windows
There are no known restrictions or limitations on directory structures when compiling on windows Compile on Linux
Building shared libraries results in a variety of .so files which applications require during link time and at run time. To correctly link in shared libraries, .so files need to be in an accessible place during both linking and run time.
Compile on Mac OSX
Mac OSX makes use of an unique concept called Frameworks. Frameworks bundle together header files, libraries and other resources together in a standard directory structure to enable client code to easily set up include and lib direcories when compiling. It is useful to set up the directory structure of a project to match what Frameworks need because
1. It makes it easier when dealing with Mac OSX and shared libraries 1. Its a useful way to organise header files and source code even for other platforms. 1. Even though SCons doesn't easily support building of frameworks now, it may in the future, and if we are prepared for it now, it will be easier later on
Taking the above points into consideration, we come up with a few key results:
- Public header files must be separate from the implementation of each library
- Source and header files for each library must be physically separate.
- For #include directives, all must use <> and have distict relative paths, such as <yafraycore/vector3d.h> or for files that do not exist in a specific library, give a distinctive file name, such as yafray_config.h
So with these in mind, the following structure is appropriate
yafray/ include/ yafraycore/ vector3d.h light.h renderer.h ... yafrayinterface/ manager.h configuration.h ... src/ yafraycore/ vector3d.cpp light.cpp renderer.cpp implementation_suff.h ... yafrayinterface/ ... yafraystandalone/ main.cpp ... StandardShaders/ phong.cpp lambert.cpp plugin.cpp StandardBackgrounds/ sunsky.cpp hdri.cpp plugin.cpp redist/ debug/ win32-msvc/ bin/ yafraycore.dll yafray.exe lib/ yafraycore.lib yafraycore.dll yafraycore.exp obj/ yafraycore/ *.obj yafraystandalone/ *.obj StandardShaders/ *.obj StandardBackgrounds/ *.obj win32-mingw/ bin/ yafraycore.dll yafray.exe lib/ yafraycore.a yafraycore.dll obj/ yafraycore/ *.o yafraystandalone/ *.o StandardShaders/ *.o StandardBackgrounds/ *.o linux32-gcc/ bin/ yafray lib/ yafraycore.so obj/ yafraycore/ *.o yafraystandalone/ *.o StandardShaders/ *.o StandardBackgrounds/ *.o macosx-codewarror/ ? macosx-gcc/ ? common/ yafray-gram.blah release/ Same as the debug structure
-- Philip Martin - 16 Nov 2004