On Jan 15, 2008 6:00 PM, Francesco Montorsi <[EMAIL PROTECTED]> wrote: > > > I'm not sure we want to force "$lua_prefix/include/lua5.1" because > > we're going to find someone with some system who has it elsewhere and > > then we'll have more problems. > typically this problem in the configure script I've found in other > packages are "resolved" putting a list of paths to check; e.g.: > > for d in /usr/local/include/lua5.1 /usr/local/include ... ; do > # check if $d is a valid folder > done
I don't think we have to ensure that it works with just "$configure" out of the box, but we do have to make it possible for people to override the paths to be able to make it work. Otherwise they're locked into some preconceived notion about how things should be, but aren't for reasons out of their control. Slackware does this: http://sotirov-bg.net/slackpack/pack.cgi?id=223&dump=true usr/include/lua/5.1/lua.h usr/lib/lua/5.1/liblua.a We've got a couple options I think: 1) Add --with-lua-libpath which fills $LUA_LIB_DIR 2) Make them do export LDFLAGS="-L/path/to/lua/lib" > > I would have kept this code, the includes can be anywhere, but the > > system Lua libs should be in usr/lib or usr/local/lib or somewhere in > > the standard lib search path > Typically, if the includes are in e.g. xxx/include/lua5.1, then the > relative library should be in xxx/lib, i.e. if headers are installed in > a certain prefix, then the library should be in that same prefix. See above. > > so I set our Lua lib path to the local > > one which is a harmless duplication. > this is in particular what I do not understand: why creating a > LUA_LIB_DIR and then set it to our local lib folder, which is not going > to ever contain the lua library if USE_SYSTEM_LUA=1? Because $LUA_LIB_DIR is used by all the compilers to specify where to put the built libs and their linking path; it replaces "$LUA_DIR/lib". In the case of USE_SYSTEM_LUA=1 we don't need it, but I imagine that it would be very hard/awkward/messy to get bakefile to not generate it for this single special case so we merely set it to the existing wxLua lib path. Since it will only be used as -L$(LUA_LIB_DIR) it does nothing new because we've already got that that lib path specified. > If we allow for an option called --with-lua-prefix then we must respect > the prefix given by the user using it as base for both the include and > the lib search folders. People do crazy things... Heck, the tgz of Lua doesn't even have an include/ dir anymore, just src/. > Anyway if the current code works, there's no need to further loose time > on it ;) I agree whole-heartedly that this build upgrade is exhausting. :) But, I think we definitely need to make it possible to completely specify the include path to Lua so it won't come up as a problem again. What do you think about the two options above for how to allow people to specify the Lua lib path? Regards, John ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ wxlua-users mailing list wxlua-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxlua-users
