Yafray directory structure

Introduction

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.

Requirements

Yafray must:

Compile without user intervention on at least
Windows
Linux
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

Proposed design

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

Dev:2.4/Source/Render/Yafray/BuildProposals

目次