|
From: k. h. <kla...@nl...> - 2005-06-03 11:36:51
|
Hi,
I like the proposal John made.
Remove indeed:
src/ - REMOVE THIS?
include/wxlua/ - REMOVE THIS?
The build directory could be here:
wxLua/thirdparty/build
wxLua/modules/build
wxLua/apps/build
and/or
wxLua/build
There is no need to create build directories in each module/program.
Thirdparty can go or made shorter,
I can imagine there will be other third party stuff, but not so
important as lua. ( e.g. xmlprc )
If there is a module directory, or all is right at the top is also not
that important.
But if putting all programs and modules and thridparty libs at the top,
this might be confusing to users too.
So it is actually to make things more clear to users to what is what.
Keeping source and include files and import files inside a "module" is
i think good.
And for the include path, it can be a single one, if all #include's in
the source code are relative to .../wxLua/module or
in the othere case .../wxLua
As you say, maybe module should be called import or bindings, and the
lua core should go up one level.
But i don;t know if bindings is always only thata, or if it sometimes
comes with extra C++ code or even lua scripts.
A more important point is the binding code, where will the result of
import files be build too.
It is a sort of prebuild step followed by the build of the c++ code.
This is how i handled it in Cmake, (using the bat/lua and shell files,
but defining it as a target to get the binding code ).
I agree that when wxLua standalone uses all settings, and some other
only a small set, this should be possible.
I think it will be complicated without editing a setup file to tune
this, unless we solve this runtime.
What if the total binding code is always generated, but that only
specific sets can be registrated to an application?
If the core and binding code are inside libraries, the code is only
linked in when used ??
I believe John already suggested this too, but i am not sure.
Why not generate the bindings in the build directory too. It is in fact
a result of a prebuild step.
After the prebuild step, the makefile take the generated c++ binding
code from there, and with the core generates the library.
For me the next would be fine. I think it contains all directories needed.
We only need to discuss if some need to move up or down in hierarchy.
If you think it is better to move all in module and/or apps and /or
thirdparty up one level, that is oke with me.
wxLua/
art/ - all images go here, preferably in XPM format
bin/ - output binaries go here, lua for example
build/ - cmake, bakefile stuff here, and call to sub build directories.
docs/ - any generic docs go here
lib/ - output libs go here, wxlualib for example
thirdparty/
build/ --build for all thridparty stuff
lua/ - lua itself
include/
src/
xmlprc/
...........
modules/
build/ --makefile for all modules.
wxluacore/ -- was "Library" (BUILT AS LIB TO wxLua/lib)
include/
src/
wxluasocket/ -- parts of "Library" that are for sockets make this a lib too
include/ (BUILT AS LIB TO wxLua/lib)
src/
wxwidgets/
(No include since no public headers)
src/ wxLuaPrinting.h/cpp, wxLuaHtml.h/cpp go here (COMPILE with makefile from modules build directory)
import/ -- was "Import" (BINDINGS GET BUILT in build directory of modules)
bit/ - there"s a lua bitwise library which might be nice
src/
wxtreelistctrl/ -- (for example, I don"t personally need this...)
import/ -- assume that the person put wxTreeListCtrl on same dir level as wxLua
..........
apps/ ?or programs?
build/ -- build for all applications
wxlua/ - the "Standalone" program
embedded/
..........
samples/ - "Examples"
samplename/ - any multifile sample should get its own dir
utils/ - generic utils, bin2c for example
Regards,
Klaas
--
unclassified
|