[Wxlua-users] Dir structure

[k. h. <kla...@nl...>]

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