Yamyam: 1版をインポートしました

2018-06-28T17:45:09Z

1版をインポートしました

wiki>Terrywallwork: /* Proposed design */

2010-03-30T20:19:25Z

‎Proposed design

新規ページ

=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

<source lang="text">
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
</source>

-- Philip Martin - 16 Nov 2004

← 古い版	2018年6月28日 (木) 17:45時点における版
(相違点なし)

Dev:2.4/Source/Render/Yafray/BuildProposals - 版の履歴

Yamyam: 1版 をインポートしました

wiki>Terrywallwork: /* Proposed design */

Yamyam: 1版をインポートしました