On 23.08.2011, at 09:39, Albrecht Schlosser wrote:

> Hmm, currently I can't follow what "the new scheme" means exactly,

OK, the old structure was like this:

./fltk3/          all FLTK3 headers
./fltk/           all FLTK2 compatibility headers
./FL/             all FLTK1 compatibility headers
./jpeg/
./png/            all supporting library headers and code and makfiles
./zlib/
./src/            all FLTK source code, all generated dynamic link libraries
./lib/            all generated static libraries
./config.h        configuration for autoconf/makefile builds - this will never 
be installed
./ide/*/config.h  configuration IDE builds - this will never be installed

For the new scheme, I decided to break up source code and headers into the same 
groups as we already did with the libraries. I find this useful because it 
clearly associates libraries with directories, it reduces the number of files 
in the directories, and it makes it possible to add and remove individual 
libraries by the core developers.

So this is the new scheme

./include/fltk3/        all FLTK3 core library headers
./include/fltk3gl/      all FLTK3 OpenGL library headers
./include/fltk3images/  all FLTK3 image library headers
./include/fltk3jpeg/    all FLTK3 jpeg library headers
./include/fltk3zlib/    all FLTK3 zlib library headers
./include/fltk/         all FLTK2 compatibility headers
./include/FL/           all FLTK1 compatibility headers
./src/core/             FLTK core source code
./src/gl/               FLTK OpenGL source code
./src/images/           ...
./src/jpeg/             ...
./src/png/              ...
./src/zlib/             ...
./lib/                  all generated static and dynamic libraries
./include/config.h      configuration for autoconf/makefile builds - this will 
never be installed
./ide/*/config.h        configuration IDE builds - this will never be installed

I believe that adding a new library (or should we call them "module"?), for 
example fltk3cairo, is now much easier, as the structure should be obvious.

(I am still undecided about naming the core source files "core". Maybe I should 
repeat the "fltk3..." naming scheme in the source code directry as well?)

> but I'd say that config.h should _not_ be in the include directory,
> i.e. it shouldn't be in any directory used for building user code.
> 
> With make, putting it into the include directory would likely cause
> it to be "installed".

Yes, I know that there is that risk. We may have to move it again.
 
Maybe my last commit log explains it a bit more detailed:

r8991 | matt | 2011-08-22 17:21:44 +0200 (Mo, 22 Aug 2011) | 43 lines

FLTK3: THE BIG FILE SHUFFLE

=== THIS RELEASE BUILDS ONLY USING THE AUTOCONF/MAKEFILE SYSTEM - IF AT ALL! ===

Ok, so here is the big file shuffle, part 1: 

 - all "simple" libraries are now included (jpeg, png, zlib become fltk3jpeg 
etc.) 
   rationale: Fluid (and all the tests) have no external dependencies, even 
   when built on a system with jpeg libraries, but run on a system without
 - all library names start with "fltk3" 
   rationale: avoid naming conflicts with fltk1 and fltk2
 - all "_" characters were removed from library names
   rationale: those seem to be unsupported in OS X framework names and cause 
warnings
 - all headers are now in a directory named include/ 
   rationale: clean up the top level directory
 - all headers are in a subdirectory strictly named after their library (jpeg/ 
-> fltk3jpeg/)
   and all sources are in a directory named after their library, minus the 
"fltk3" (jpeg/ -> src/jpeg/)
   rationale: allow auto-genration of build environments for further additional
   libraries in FLTK3, for example fltk3cairo, etc. . 
 

Still to do:

 - Fluid will become Fluid3
   rationale: avoid naming conflicts with fltk 1 and 2
 - fltk gl headers go into include/fltk3gl/, fltk images headers in 
include/fltk3images
   rationale: additional libraries always have their headers named in the same 
naming system
 - add 'all.h' and '`libname`.h' to all include directories
   rationale: this will make work with the libraries easier by allowing 
#include <fltk3/all.h>
   which includes everything available. It helps debugging header files, and it 
will be consistent
   among libraries (#include <fltk3gl/all.h>). It also accelerates compilation 
when using
   precompiled headers. And last-not-least, the alternative syntax #include 
<ftk3/fltk3.h> 
   is standard for OS X frameworks.
 - rename Fl_... .cxx files into their FLTK3 name counterpart
   rationale: avoid confusion with FLTK 1 class naming

I hope you guys are not completely shocked by this commit and will stick with 
me.
Nothing really changed or moved further than one directory away.

 - Matthias




_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev

Reply via email to