Re: [Wxlua-users] Dir structure

[John L. <jla...@gm...>]

> There is no need to create build directories in each module/program.

Agreed.
=20
> 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

I think I'm starting to agree about separating them, how about putting
all the c/c++ code into the "module" directory and forget the
"thirdparty" dir all together, see #1 below.
=20
> As you say, maybe module should be called import or bindings, and the
> lua core should go up one level.

I think bindings should go into their own dir to separate them,
grepping through them will be easier since you won't have to slog
through all the c++ code.

> But i don;t know if bindings is always only thata, or if it sometimes
> comes with extra C++ code or even lua scripts.

Yes there are the wxLuaPrinting, wxLuaHtmlWin for example, these are
necessary to make use of vitual c++ functions. I think we can even
#include these inline in the wrappers to simplify things. Perhaps
someday (not soon through) virtual functions could be implemented
differently, but I don't think this will imact the dir structure.
=20
> 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.

The only solution I can think of is making each project compile the
wrapper bindings to their own object files and link to them. This is
exactly what we do now with the wxLuaWrap.cpp file. We can also
provide build files to make a library of all the wrappers, this is
what the wxlua program itself will use and people can use it as well.
I think any individual project will have very different requirements
and we don't have a good handle on how to do this so lets leave it up
to them for now.

Bottom line, a user's program can either use the complete set of
wrappers and take advantage of the wxLua app's build files or use
their own build files to customize it.

> What if the total binding code is always generated, but that only
> specific sets can be registrated to  an application?

I think it would be a good idea to be able to reduce the size of wxLua
when linked to another program. The wrappers are pretty hefty, but as
I said we'll be providing this option since this is what the wxLua app
will do.

> If the core and  binding code are inside libraries,  the code is only
> linked in when used ??

I think because the wrapper functions are stored in structs they won't
get stripped out by the linker.

> Why not generate the bindings in the build directory too. It is in fact
> a result of a prebuild step.

We'll probably end up with premade cpp bindings that you'll link to.
Ray has added wxUSE_XXX ifdefs in them so that they'll work no matter
how a user's wxWidgets is setup (in linux using configure or msw using
msw/setup.h)

Of course, it seems like there's no reason why you couldn't build your
own set of wrappers on the fly and put them wherever you like.

> 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.

Ok, I prefer #1, but I left in #2 as the "other way" of doing it.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
The two schemes both share these dirs

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
      /samples/            - "Examples"
          /samplename/     - any multifile sample should get its own dir
      /utils/              - generic utils, bin2c for example
      /apps/    ?or programs?
          /build/              -- build for all applications
          /wxlua/              - the "Standalone" program
          /embedded/ =20
          /runtime/        - as Ray suggested, a stripped down runtime for =
wxLua
     /bindings/  - input *.i files to make the "wrappers"
        wxluawrap.lua goes in this dir so it's easy to get to for your
own projects
        /wxwidgets/ all the current .i files=20
        /bit/ - the bitwise lib for lua, maybe nothing needed here
        /other .i files for other stuff.../
    /wrappers/
        /wxwidgets/ =3D output of bindings and wxLuaPrinting, wxLuaHtmlWin
        /bit/ =3D the wrapper is the "src" of the bit library
        /output of other .i files for other stuff.../

I may have the notion of bindings and wrappers backwards though?

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
1.) Use a module approach
     /modules/
        /build/ - to have build files for all of this
        /lua/     -- lua itself
             /include/
            /src/
            /the rest of lua.../
        /wxlua/         - the wxlua library itself
            /include/ =3D internal.h, interp.h, library.h
            /src/  =3D internal.cpp, interp.cpp, library.cpp
        /wxluasocket/ - lua to cpp sockets (the current lua sockets)
            /include/ =3D debugio.h, socket.h=20
            /src/ =3D debugio.cpp, socket.cpp
        /wxluadebug/ - mechanism for getting/showing info from lua
            /include/  =3D debug.h, stacktree, splittree
            /src/ =3D debug.cpp, stacktree, splittree
        /xmlrpc/ - is is a generic lib right? so don't prepend wxlua to it?
            /include/ =3D ... Rays stuff
            /src/ =3D ... Rays stuff
        /debuggernub/ - this is a generic lib for xmlrpc? don't
prepend wxlua to it
            /include/  =3D ... Rays stuff
            /src/ =3D ... Rays stuff
        /wxluadebugger/ - this depends on wxlua so prepend wxlua to it
            /include/  =3D ... Rays stuff
            /src/ =3D ... Rays stuff

I think Klaas is suggesting that a user will set the include path to
wxLua/modules and then in a cpp file do
#include "wxlua/include/xxx.h"=20
I was confused about this.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
2.) Make it look like wxWidgets
    /lua/ - lua itself in root dir since this is what this is all about
        /include/
        /src/
        /the rest of lua.../
    /include/
        /wxlua/ =3D internal.h, interp.h, library.h
             /socket/ =3D debugio.h, socket.h=20
             /debug/ =3D debug.h, stackframe.h, splittree
             /debuggernub/ =3D ... Rays stuff
             /debuggee/ =3D ... Rays stuff
             /xmlrpc/ =3D ... Rays stuff
    /src/ =3D internal.cpp, interp.cpp, library.cpp
        /socket/ =3D  debugio.cpp, socket.cpp
        /debug/ =3D  debug.cpp, stackframe, splittree
        /debuggernub/ =3D ... Rays stuff
        /debugger/ =3D ... Rays stuff
        /xmlrpc/ =3D ... Rays stuff

In this case you just have "wxLua/include" in your build files and just=20
#include "wxlua/xxxdir/xxx.h" in your cpp files.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D

In both cases we'll build wxlualib, wxluasocketlib, wxluadebuglib,
debuggernublib, xmlrpclib, and

I vote #1.

Regards,
    John Labenski