Re: luasetup.h and wxLua build system (was Re: [Wxlua-users] wxLua Compiles and works in Linux)

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

> > In principle the copy is already made, to your own project. It has
> > nothing to do with SHARED, UNICODE etc.
> > Still for one luasetup.h all those type of builds ( synchromized with
> > the wxWidgets in WXWIN) should be generated. They do not variate with
> > lausetup.h, but only because of build type.
> ok, that is: we want separate build folders for different build settings =
and not only
> (through the WXLUASETUP_DIR and WXBIND_TARGET_LIBDIR options) for differe=
nt luasetup.h.
> Anyway this is already in place; i.e. object files are sent to the
> build\msw\[compiler][u][d] folder and library files into lib\[compiler]_[=
dll|lib]).
> So, no problem ;)

Precisely.

> >>> HOWEVER! This cannot be made to work for MSVS dsp files, can it?
> >>
> >> right; unfortunately IDEs do not allow you to specify options which
> >> are in "string" form. That is, you can make multiple configurations in
> >> a DSP file for an option which has a finite set of possible values
> >> (like BUILD=3Ddebug/release) but you can't do that for a "path" option=
.
> >
> > Hmmm, i really see /I$(WXWIN)\lib\.
> > Is that not enough to do the trick ?
> I forgot about environment variables.
> But you're right; they could solve the problem: we ask the user to set a =
WXLUASETUP_DIR
> and WXBIND_TARGET_LIBDIR env variables and then use these in the DSP.
> However this means that just downloading wxLua and open the DSW file won'=
t work: the user
> will also need to set the env variables first as this way do not allow to=
 specify a
> "default-value-in-case-the-env-var-is-missing"...
>
> So I don't know if it's better to limit project files to the default luas=
etup.h or to
> force them to look for the WXLUASETUP_DIR and WXBIND_TARGET_LIBDIR env va=
rs...

Nah, this won't work too well. Let's say there's a bug in wxLua, maybe
the .i files are messed up and some function doesn't work. You fix
them and regenerate with genwxbind that outputs into modules/wxbind.
Now you need to recompile wxbind and relink your program, BUT! you
should also test apps/wxlua to see if you didn't break that by
accident. So, you need to compile the default wxbind lib and relink
apps/wxlua. Using environment variables means that you open VS to do
your app, close it, reset env vars and open it again to do apps/wxlua,
close it, reset env vars, go back to your app.

I think Francesco had it right, if you use dsp files you get the
default wxbind lib, if you really want your own wxbind lib you copy
the dsp file that builds wxbind and edit it yourself, tough luck on
them. :(  It's actually not too much work for them really. In fact
they can just put their own copy of the bakefile used to build wxbind
right into their project tree, modify it as necessary to point back to
wxLua, and generate their own project files to use.

* The bottom line: It sounds like the /I include "trick" is our best
best that'll work for the most number of compilers. If there are no
objections, lets do it this way and move on to the next hurdle, how to
use your own .i files with wxLua.

Thanks,
    John Labenski