Francesco Montorsi wrote:
> Hi,
> thinking to implementation of the WXLUASETUP_DIR and
> WXLUABINDLIB_DIR options, I realized one thing.
>
> I.e. if I want to install app X (from sources) which has its own wxLua
> extensions, then I cannot just compile&install wxLua with a standard
> "./configure && make && make install" (on win32 "cd wxLua/build/msw &&
> nmake -fmakefile.vc"): app X requires wxLua's build options to be
> modified (i.e. adding something like WXLUASETUP_DIR=X/luaext
> WXLUABINDLIB_DIR=X/lualib).
>
> Ok, this affects only source builds and it won't be the first case
> that such thing happens. However I think that if that can be avoided,
> it would be a Good Thing.
Absolutely, wxLua is one fixed thing which can be compiled and installed
, recompiling whatever bindings in an App, using binding files from
wxLua is another thing.
>
> One way to avoid that could be providing the app X with a way to
> recompile the wxLua's wxbind module with its own wxluasetup.h.
Rigth and also the location of the library generated as result.
> This means that the custom wxbind module would not be generated when
> wxLua is compiled but rather when app X is compiled.
Exactly, the app only uses stuff from there.
>
> I'm not sure if you had this same idea when you wrote that
> WXLUASETUP_DIR and WXLUABINDLIB_DIR options should not be exposed in
> the configure script :)
>
At least you got it somehow, but indeed that is what i meant to explain :-)
> Anyway, on Unix, it wouldn't be such difficult to provide to the guest
> app X the required info to recompile wxLua's wxbind module.
> It would probably be somewhat more difficult on win32, but probably
> still feasible.
I think setting the variables inside the App its makefiles should/could
do the job.
Why would it be complicated ? If the variabes are set, you the same as
with wxbind, but here with different locations.
>
>
> What do you think of this approach ?
I think it right,
Klaas
|
