From: Francesco M. <f18...@ya...> - 2005-09-10 16:43:48
|
Hi, Ulrich Telle wrote: > Hi Francesco, > > >>>configure did not work since it believed that the makefiles were >>>created by bakefile 0.1.9 although I definitely created them with >>>0.1.9.1. I changed the version number in autoconf_inc.m4 from 0.1.9 >>>to 0.1.9.1. >> >>yes; this is a bug in the latest version of bakefile which has already >>been solved in the CVS. I forgot to mention it, sorry. > > > If it's not already there I would suggest to add this information to > the wxCode maintainer guide. done ;) > The good news is, that wxPdfDocument compiles and runs on Linux without > further problems (if the makefile is ok, that is). good ! usually with non-graphical components using wx I get *exactly* the same behaviour under all platforms; with graphic components the bugs I found to be present in a platform and not in another one are usually due to an incorrect use by me of some wx feature :) >>>2) What changes are needed that the component's library name reflects >>>for which wxWidgets build it was created? >> >>the libname should get the [u][d] postfix like it does on windows... but it won't use >>exactly the same naming convention used by wx under unix... (i.e. >>libwx_[gtk2,x11][u][d]_sublib-MAJOR.MINOR.so.0.RELEASE.0) > > > I'll check whether this works for my component tomorrow. Where can I > set MAJOR, MINOR and RELEASE for my own component? well, the string libwx_[gtk2,x11][u][d]_sublib-MAJOR.MINOR.so.0.RELEASE.0 is a description of the naming convention for wx used on unix-like systems. If you don't need it and you like the usual libCOMPNAME[u][d].a (for static builds) or libCOMPNAME[u][d].so.0.0.0 (for shared builds) then you don't need to change anything in your component bakefile. anyway, if you want to set version numbers for your components, you should use the tags: <version>MAJOR.MINOR</version> <so_version>0.RELEASE.0</so_version> <mac_version>0</mac_version> in your component_dll target. As you can see in wxcode/build/bakefiles/templates.bkl the default settings for these tags (which have sense only for shared builds) are: <version>1.0</version> <so_version>0.0.0</so_version> <mac_version>0</mac_version> You should override them in your component's bakefile to implement versioning. NOTE: I'm not sure at 100% that MAJOR, MINOR and RELEASE must be used as I told above: <version>MAJOR.MINOR</version> <so_version>0.RELEASE.0</so_version> <mac_version>0</mac_version> in fact the unix shared library versioning is quite complex since it allows to do a lot of things; I read a linux HOWTO some time ago but I also forget most of it :) In bakefile docs these tags are not described so I think that MAJOR, MINOR and RELEASE should be used that way but I cannot grant it. >>the Makefile created by configure can be used only for the >>configuration you told to "./configure"... if you need to use another >>wx build, you should do a "make install" for that wx build and then >>relaunch your component's "configure" script. > > > Ah, ok, I understand. (I'm very new to Linux, you know.) ;) >>The Makefile will be adapted to the currently installed build of wx >>(and here comes in the bug I told you in some previous mail: wx build >>flags detection is buggy in wxcode bakefiles since prior 2.6.2 it was >>not possible to detect them easily). > > > Absolutely true. I built 4 different versions of wxWidgets (ANSI, ANSI > DEBUG, UNICODE, UNICODE DEBUG). wxCode configure said in the message > UNICODE DEBUG but created a makefile for ANSI without DEBUG. > > This will be corrected in 2.6.2? sure; I'm just waiting for 2.6.2 which will have a new option in the "wx-config" script which I'll use to set WX_* option vars. Unfortunately an easy way to set them won't be integrated directly in wx since Bakefile author's does not think it's a good thing; even if I asked him many times his replies did not give any reason for this motivation - I'm not going to insist anymore since I fear that he will try to kill me; this thing gives me hell !! This is the text of the mail he sent me recently: Vaclav Slavik wrote: > Hi, > > Francesco Montorsi wrote: > [...] >>(or something like that, possibly shorter :-)) option which, only >>in case it is used, sets the WX_* options so that people who want >>to give to their wx-based libraries a name with, for example, >>[u][d] postfix, can use these info to set all their variables to be >>substituted into Makefile.in... do you think this is not a good >>approach ? > > > No. I really don't know what should I do to get the message through if > repeatedly explaining it to you is apparently not enough :( -- the > WX_* options are *NOT* part of wxpreset's public API, you should > *NOT* use them for *ANYTHING*. and more info at: http://sourceforge.net/tracker/index.php?func=detail&aid=1254557&group_id=9863&atid=309863 So, he decided that wxpresets won't be useful for developers like me and you who want to give to their components an easy unix build system, i.e. which detects automatically wx build flags. This means that I'll have to ship an additional .m4 macro file in wxcode/build/bakefiles folder which maintainers will need to install to write shorter configure.in/ac files. And this also means that I'll have to do that in all my wx projects, grrrrrrr. In conclusion, also with wx2.6.2 creating a good "configure" script won't be as easy as it could be. > I guess not every wxWidgets user will switch to 2.6.2 immediately. Is > there a way to support pre 2.6.2 users? the only way I can see is to write a configure.in/ac file which gives to the user the options: --enable-debug --enable-shared --enable-unicode --with-gtk --with-x11 --with-motif --with-mac --with-msw which the user *must* use to indicate to the configure script of its component the same configuration he told to the configure script of wxWidgets. I'm a little busy now; I'll try to implement this in a reusable way first in my components and then put some info about this in wxcode/build/bakefiles/readme.txt. Francesco |