[Bf-committers] some findings about code fitness

[Jean-Luc Peuriere]

Hi,

I'm in the process of creating an XCode native project for the mac (I 
know i swore i would not do it unless automaticaly, only fools dont 
change advice). It works already but need testing and fine tuning. To 
benefit from the zero linking stuff, i needed to put all in one global 
project renouncing to the libraries structures. this leaded to some 
discoveries and thoughts :

-  Scons include and lib path managing is very dumb. in worse case the 
same location is repeated up to 7 times (!!!!!!!) and both the original 
location and the installation ( in ../lib/darwin.....) is listed. This 
should be corrected, as even if it works, there is overhead associated 
with that.

- the need to include from numerous submodules leads to very long list. 
a good way imho would be to list as include path only  :
	- $root/intern
	- $root/extern
	-$root/source/blender
	-$root/source/creator
	-$root/source/gameengine
	-$root/../lib/ ..............

where $root is blender home dir.

      from there to include a particular file, instead of eg  #include 
"BLI_editVert.h", you do #include "blenlib/BLI_editVert.h"
     not much change, nicer and easier setup, and a single glance let 
you know where a particular file is.

    Now, that's quite an editing, but worthwhile (Hos, i can feel you 
have murder thoughts right now ;). I could volunteer on doing that (not 
now though).

    this also solve the case of similary named includes (utils.h exist 
twice)

- the prototypes are very variously used, and may lead to problem (you 
can end with a function returning implicitly int instead of its correct 
value). Numerous C files dont include their own interface .h file

- even if the correct include exist, it is sometimes not used.

- there is a number of unused files (especially in intern or game 
engine) both for testing and dead code. those should be identified.
I know that CVS dont allow to rename or move files easily, but that's a 
problem to grasp which code is used

- the MT lib use in some files #include "MT/xxxxxx.h" instead of the 
correct "MT_xxxxxx", this is ok if the correct file is included first

- we should really kill as much warning as possible, the crucial ones 
are hidden behind the unimportant. I'm preparing quite a patch
which kill hundreds of warnings  (many harmless, but not all, most of 
the prototypes). this patch will have to be reviewed both by module 
owners and platform managers.

- do we really need to install all intern and extern libs in 
$root/../lib ? they are in any case in the build system own tree and 
the headers available at their
place. For the extern, i understand, but we always build intern, no ? 
Even for extern, it should be a toggle, use precompiles or build, but 
no need to install
(except for platform maintainers)

- for Os X using the OpenGL framework is ok, we should test if it is 
faster than linking to the libs (it should as it is in any case used by 
system)

- does all platform support the #pragma unused ?
-- 
Jean-Luc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 3052 bytes
Desc: not available
Url : http://projects.blender.org/pipermail/bf-committers/attachments/20050228/f5154eb3/attachment-0001.bin