Re: [Wxlua-users] wxLua Compiles and works in Linux

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

Ok, here's the scenario.

$cvs co wxLua  # get clean wxLua tree
$cd wxLua/build/msw && nmake -f makefile.vc # build everything

So far so good, you don't have to do anything other than build it to
get a completely working wxLua (the IDE app). [If we want we can have
the luasetup.h for the IDE as luasetup0.h, but I can't think of why
you wouldn't want the full bindings for it.]

* Now - here's my issue. You have your own project (in it's own tree)
that uses wxLua as a library. You may want a smaller version of the
bindings, so you'll need your own luasetup.h in your own project's
files that you maintain where you've turned off some things that will
never be used.

$cd myproject/build && nmake -f makefile.vc

****************************
Now for the wxLua developers, we'll work on wxLua and then have to
rebuild both the wxLua IDE and our projects to test things. This means
that there will be two different lib_wxluabind. I do *not* want to
have to copy/edit luasetup.h or do anything other then just type make
for each. I also need to be able to run them both at the same time for
testing.

I hope this makes it a little more clear why I want this to work seamlessly=
.

****************************

In terms of copying the luasetup.h that was used to generate each
library, it's probably not necessary since it's part of your project
and you can get at it yourself.

**********************************
The solution: (or the only way I see it working)

1) In modules/wxbind/include/wxbind.h we have #include "luasetup.h"
with *no* path before it.

2) We put a complete version of luasetup.h in
modules/wxbind/src/luasetup.h so it'll be included using the default
search path of ./ that all compilers support.

3) In the makefile for wxluabind we have
WXLUASETUP_DIR =3D ./
.cpp.o:
        $(CXX) -I $(WXLUASETUP_DIR) -c $(CXXFLAGS) $(APPEXTRADEFS)-o $@ $<

so that by default it uses the luasetup.h in modules/wxbind/src and
when you call the makefile from your project's makefiles you define
WXLUASETUP_DIR =3D "path/to/my/project/where/my/luasetup/is"
so it'll find your own luasetup.h first.

4) In the makefile for wxluabind we have
WXBIND_TARGET_LIBDIR =3D $(WXPREFIX)/lib (or whereever)
so that again, in your own project files you can do
WXBIND_TARGET_LIBDIR =3D /some/path/to/somewhere/else

Now you can have two different libs for two different luasetup.h at
the same time.

HOWEVER! This cannot be made to work for MSVS dsp files, can it?

**********************************

On 11/21/05, Francesco Montorsi <f18...@ya...> wrote:
> Sorry but I'm missing the point of this discussion; maybe because it's la=
te here ;)
> I don't understand if the problem is:
>
> 1) be able to build wxLua against different wxWidgets configurations
>     (which can be solved using as output dir lib/$(COMPILER)_[dll|lib])
> 2) be able to build wxLua with different luasetup.h files
>     (which I would solve, on win32, using the same approach taken by wxWi=
dgets, see below).
>
> I guess the problem is mainly #2... in this case:

Yes #2, luasetup.h has little if nothing to do with wxWidget's setup.h.

> >> The biggest problem, I think, is how to use two luasetup.h files
> >> without having to copy the new one into place between builds.
> >>
> > Right, i see. Maybe the wxWidgets way of copying the setup.h to some th=
e
> > lib dir first before starting to compile. That is: it only copies it if
> > not already there.
> as Klaas said, wxWidgets keeps a different setup.h for each different com=
binations of
> SHARED/BUILD/UNICODE options. If the corrispondent setup.h (located in
> $(WXWIN)/lib/$(COMPILER)_[lib|dll]/msw[ud]/wx/setup.h IIRC) does not exis=
t, then a default
> one is copied there.
>
> So for the user it's "easy" to customize his wx builds: he creates its se=
tup.h (probably
> modifying the default one) in the right folder and then gives the makefil=
e command.
> This system works even for IDEs...

The thing is, luasetup.h doesn't care what platform or build you're
using. The bindings themselves have all the wxUSE_XXX that are defined
in wxWidget's setup.h.

> > The problem is the to have the makefile use setable output directories
> > for libraries and object files, so one can have several builds.
> > I wonder how wxWidgets developers  test  different  setup.h  combinatio=
n.
> I don't know this... but I'd like to ;)

As you probably saw, I ased on wx-users, but I don't think it's really poss=
ible.

-John