Hi Francesco, I like the two target names to be changed, since else i can not use them the same way with Cmake. Actually it is more a VC project problem, cmake does generate them correctly. The problem is that there is a lua executable and a lua library, and the same for wxlua. Especially the lua itself is causing me problems, since that target is used to generate the binding too. So it name should be lua(.exe) Can the library names be changed to wxlual and lual ? ( i wonder anyway what happens if our internal lua is installed, and it conflicts with a lua lib installed form some other source. So it might not be a bad idea to name ours different. ) thanks, Klaas -- Unclassified
Forget this one, i solved using Cmake tricks. But the install point is still something to think about. k. holwerda wrote: > Hi Francesco, > > I like the two target names to be changed, since else i can not use > them the same way with Cmake. > Actually it is more a VC project problem, cmake does generate them > correctly. > The problem is that there is a lua executable and a lua library, and > the same for wxlua. > Especially the lua itself is causing me problems, since that target is > used to generate the binding too. > So it name should be lua(.exe) > > Can the library names be changed to wxlual and lual ? > > ( i wonder anyway what happens if our internal lua is installed, and > it conflicts with a lua lib installed form some other source. So it > might not be a bad idea to name ours different. ) > > thanks, > > Klaas > > -- Unclassified
Hi, k. holwerda ha scritto: >> I like the two target names to be changed, since else i can not use >> them the same way with Cmake. >> Actually it is more a VC project problem, cmake does generate them >> correctly. >> The problem is that there is a lua executable and a lua library, and >> the same for wxlua. >> Especially the lua itself is causing me problems, since that target is >> used to generate the binding too. >> So it name should be lua(.exe) >> >> Can the library names be changed to wxlual and lual ? >> >> ( i wonder anyway what happens if our internal lua is installed, and >> it conflicts with a lua lib installed form some other source. So it >> might not be a bad idea to name ours different. ) I agree we need to redefine the names of the libraries created by wxLua. Specially to avoid conflicts with LUA libraries installed from other sources, if this is necessary. So, 1) is the lua library compiled with wxLua different from the 'standard/official' lua library ? I think it is because I saw the symbol WXLUA_CODE defined when compiling lua... 2) how do we name the wxLua libraries ? Currently I see in wxLua/lib: -rw-r--r-- 1 frm frm 674700 2006年01月24日 10:13 liblua.a -rw-r--r-- 1 frm frm 128872 2006年01月20日 13:40 liblualib.a -rw-r--r-- 1 frm frm 13821610 2006年01月25日 18:47 libwxbind.a -rw-r--r-- 1 frm frm 1706004 2006年01月24日 10:14 libwxlua.a -rw-r--r-- 1 frm frm 1320170 2006年01月24日 10:19 libwxluadebug.a -rw-r--r-- 1 frm frm 1812618 2006年01月24日 10:19 libwxluasocket.a but I know that John's hand written makefiles have a more wx-like library namings. We could name them as: libwxlua_[gtk2|x11|msw|...][u][d]_lua-[wxversion].so.0 libwxlua_[gtk2|x11|msw|...][u][d]_lualib-[wxversion].so.0 libwxlua_[gtk2|x11|msw|...][u][d]_wxbind-[wxversion].so.0 libwxlua_[gtk2|x11|msw|...][u][d]_wxlua-[wxversion].so.0 libwxlua_[gtk2|x11|msw|...][u][d]_wxluadebug-[wxversion].so.0 libwxlua_[gtk2|x11|msw|...][u][d]_wxluasocket-[wxversion].so.0 Do you agree ? Francesco
Francesco Montorsi wrote: > Hi, > > > libwxlua_[gtk2|x11|msw|...][u][d]_lua-[wxversion].so.0 > libwxlua_[gtk2|x11|msw|...][u][d]_lualib-[wxversion].so.0 > libwxlua_[gtk2|x11|msw|...][u][d]_wxbind-[wxversion].so.0 > libwxlua_[gtk2|x11|msw|...][u][d]_wxlua-[wxversion].so.0 > libwxlua_[gtk2|x11|msw|...][u][d]_wxluadebug-[wxversion].so.0 > libwxlua_[gtk2|x11|msw|...][u][d]_wxluasocket-[wxversion].so.0 > > Do you agree ? > I do agree! Klaas -- Unclassified
Hi, k. holwerda ha scritto: > > > Francesco Montorsi wrote: > >> Hi, >> >> >> libwxlua_[gtk2|x11|msw|...][u][d]_lua-[wxversion].so.0 >> libwxlua_[gtk2|x11|msw|...][u][d]_lualib-[wxversion].so.0 >> libwxlua_[gtk2|x11|msw|...][u][d]_wxbind-[wxversion].so.0 >> libwxlua_[gtk2|x11|msw|...][u][d]_wxlua-[wxversion].so.0 >> libwxlua_[gtk2|x11|msw|...][u][d]_wxluadebug-[wxversion].so.0 >> libwxlua_[gtk2|x11|msw|...][u][d]_wxluasocket-[wxversion].so.0 Just a few things which came up to my mind while updating bakefiles: 1) on win32 it's best not to use a version in the libname with dots (instead of 2.6, we should use 26); furthermore, we can even choose to use the same wx library convention: wxmsw[wxversion without dots][u][d]_[libname].lib So, what do you propose? I think that while on linux we can adopt a more complex library naming (like libwxlua_[gtk2|x11|msw|...][u][d]_lua-[wxversion].so.0) since the user will probably use `pkg-config wxlua --libs` to get libname, on win32 we should keep the library name shorter as wxWidgets does. Thus I suggest to stick with wx rules for both linux and win32 libnames. 2) We are going to put wxversion numbers somewhere in library names in any case. However I'd like to discuss a couple of things about version. I see wxPython works this way: for wx2.6.2 there is wxPython2.6.2.1, wxPython2.6.1.2, etc... This is probably the best thing to do as it will be simpler for users to understand which release of wxPython targets which release of wxWidgets but still lets wxPython developers to make other releases still targeted to wx 2.6.2 using the fourth digit. Do you agree to use this versioning rule ? AFAIK the only files containing wxLua version numbers should be: 1) build/bakefiles/wxluabase.bkl 2) build/autoconf/configure.ac If we decide to use a wxPython-like versioning, then we can store a single version number in these files (the fourth number). In any case we would still use only wx major and minor version digits in libnames, unless someone has other ideas.... Francesco
Francesco Montorsi wrote: > > Thus I suggest to stick with wx rules for both linux and win32 libnames. Fine with me, but will the next become? wxmsw[wxversion without dots][u][d]_[libname].lib wxl_msw_wxluaversion without dots][u][d]_[libname].lib As you see wxl_ is i think better then wxmsw. It must be clear we are taliking wxLua. Same i would say: a2d_msw etc. > > > > 2) We are going to put wxversion numbers somewhere in library names > in any case. However I'd like to discuss a couple of things about > version. > > I see wxPython works this way: for wx2.6.2 there is wxPython2.6.2.1, > wxPython2.6.1.2, etc... > This is probably the best thing to do as it will be simpler for users > to understand which release of wxPython targets which release of > wxWidgets but still lets wxPython developers to make other releases > still targeted to wx 2.6.2 using the fourth digit. > > Do you agree to use this versioning rule ? I think this is confusing, since those numbers normally mean something else. Also i do not think that wxLuaversionX will be different for different version of wxWidgets. At least that was the goal of the *.i files. I would keep the versions of wxLua and wxArt2D independent from wxWidgets. It should be in the install.html and configure etc. ( there are/will be more dependencies, so where would one stop??) Also i am thinking in the future wxWidgets might get to the level that wxCode stuff will be moduler/pluggable. In that case we certainly not have the situation that each module goes in the same pase with wxWidgets. So better decide a solution that works always in al situations, which is what i think keep the version seperated. regards, Klaas
Hi, klaas.holwerda ha scritto: > Francesco Montorsi wrote: > >> >> Thus I suggest to stick with wx rules for both linux and win32 libnames. > > > Fine with me, but will the next become? > > wxmsw[wxversion without dots][u][d]_[libname].lib > > wxl_msw_wxluaversion without dots][u][d]_[libname].lib > > As you see wxl_ is i think better then wxmsw. > It must be clear we are taliking wxLua. maybe you're right; but I would then use (for win32): wxlua_msw[wxversion without dots][u][d]_[libname].lib >> 2) We are going to put wxversion numbers somewhere in library names >> in any case. However I'd like to discuss a couple of things about >> version. >> >> I see wxPython works this way: for wx2.6.2 there is wxPython2.6.2.1, >> wxPython2.6.1.2, etc... >> This is probably the best thing to do as it will be simpler for users >> to understand which release of wxPython targets which release of >> wxWidgets but still lets wxPython developers to make other releases >> still targeted to wx 2.6.2 using the fourth digit. >> >> Do you agree to use this versioning rule ? > > > I think this is confusing, since those numbers normally mean something > else. what do they mean ? AFAIK the fourth digit of wxPython indicates the version of wxPython wrappers while the first 3 indicate the version of wxWidgets which must be used with those wrappers. > Also i do not think that wxLuaversionX will be different for different > version of wxWidgets. > At least that was the goal of the *.i files. Yes but say that after releasing wxLua 2.6.2 we found that there is a small bug in wrapper generator which needs to be fixed. How do we call the next release (still targeted for wx2.6.2) ? Using 4th digit there's no such problem: the new version would be 2.6.2.2 > I would keep the versions of wxLua and wxArt2D independent from wxWidgets. I agree for wxArt2d but not for wxLua. wxLua is a wrapper and I'd take inspiration for such things from the well-known wxPython package. > Also i am thinking in the future wxWidgets might get to the level that > wxCode stuff will be moduler/pluggable. I hope it, too :) > In that case we certainly not have the situation that each module goes > in the same pase with wxWidgets. > So better decide a solution that works always in al situations, which > is what i think keep the version seperated. 3d party code (like contribs or wxCode components) should always be checked by wxLua configure script or CPP code for its version. IMO this is an independent issue from the type of versioning we choose for wxLua... Francesco
> >> 2) We are going to put wxversion numbers somewhere in library names > >> in any case. However I'd like to discuss a couple of things about > >> version. > >> > >> I see wxPython works this way: for wx2.6.2 there is wxPython2.6.2.1, > >> wxPython2.6.1.2, etc... > >> This is probably the best thing to do as it will be simpler for users > >> to understand which release of wxPython targets which release of > >> wxWidgets but still lets wxPython developers to make other releases > >> still targeted to wx 2.6.2 using the fourth digit. ... > > AFAIK the fourth digit of wxPython indicates the version of wxPython > wrappers while the first 3 indicate the version of wxWidgets which must > be used with those wrappers. > > > Also i do not think that wxLuaversionX will be different for different > > version of wxWidgets. ... > > > I would keep the versions of wxLua and wxArt2D independent from wxWidge= ts. > I agree for wxArt2d but not for wxLua. wxLua is a wrapper and I'd take > inspiration for such things from the well-known wxPython package. I agree that we should use the 2.6.2.X versioning for wxLua. The .i files do try to maintain backwards compatibility as they move forwards, but it's a drag trying to keep them working for 2.4 and so by naming wxLua2.6.2.x we're suggesting to people that this is what version wxLua is targeted for. For example the MSVC dsp files use 26 in them. People are welcome to hack away to make it work for other versions and perhaps it will, but the numbering implies that it should work out of the box for that version of wxWidgets. Regards, John Labenski
John Labenski wrote: >I agree that we should use the 2.6.2.X versioning for wxLua. > Oke then lets do it like that. Klaas
klaas.holwerda ha scritto: > John Labenski wrote: > >> I agree that we should use the 2.6.2.X versioning for wxLua. >> > Oke then lets do it like that. Ok, updated the bakefiles. Now the configure scripts sets the wxLua version after detecting the wx's one and adding the WXLUA_RELEASE var's content to it. Francesco