wxcode-users

[wxCode-users] wxCode bakefiles for unix (was Re: ANN: wxPdfDocument 0.5 released)

[Francesco M. <f18...@ya...>]

Hi,

Ulrich Telle wrote:

> Not really. 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.

>Thereafter I could exceute configure without error messages. 
> But when executing make I got
> 
> cc1plus:
> File or directory not found:
> opening dependency file
> autoconf_dll/wxpdfdoc_dll_pdfdoc.d
> 
> The reason is that I had added the line
> 
> <set var="BUILDDIR">$(FORMAT)$(WXLIBPOSTFIX)$(POSTFIX)</set>
> 
> to the bakefile of my component, so that I'm able to build my component 
> for different wxWidgets configurations like ANSI, UNICODE, with or 
> without DEBUG etc., but the makefile does not create the directory if it 
> does not exist (as does MSVC). I created it manually. make then worked.
> 
> I still have several questions:
> 
> 1) What changes are needed in my component's bakefile or elsewhere so 
> that the BUILDDIR directory is created if it does not exist?
that's not an easy thing like it could seem.
Please seem my old post (and the replies):

http://article.gmane.org/gmane.comp.sysutils.bakefile.devel/142

for more info.
In short, you should not use BUILDDIR != "." with autoconf since the author of Bakefile 
decided not to support automatic BUILDDIR creation with autoconf and it's not easy to add 
this manually.
Thus I suggest you to use:

<if cond="FORMAT!='autoconf'">
<set var="BUILDDIR">$(FORMAT)$(WXLIBPOSTFIX)$(POSTFIX)</set>
</if>


> 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)


> 3) How do I create my component for different wxWidgets builds using the 
> Makefile created by configure? Is it sufficient to specify for example 
> -DDEBUG and/or -DUNICODE when invoking make? Or whatelse is needed?
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.
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).

Francesco

PS: I'm moving the thread from wxusers to wxcode since I think it's more relevant there.

Re: [wxCode-users] wxCode bakefiles for unix (was Re: ANN: wxPdfDocument 0.5 released)

[Ulrich T. <Ulr...@gm...>]

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.

> > 1) What changes are needed in my component's bakefile or elsewhere so 
> > that the BUILDDIR directory is created if it does not exist?
> that's not an easy thing like it could seem.

What a pity.

> In short, you should not use BUILDDIR != "." with autoconf since the
> author of Bakefile decided not to support automatic BUILDDIR creation
> with autoconf and it's not easy to add this manually. 

Ok, good to know.

> Thus I suggest you to use:
> <if cond="FORMAT!='autoconf'">
> <set var="BUILDDIR">$(FORMAT)$(WXLIBPOSTFIX)$(POSTFIX)</set>
> </if>

I'll adjust my component's bakefile. I'll experiment until I get 
something which works on Linux without too much difficulties.

The good news is, that wxPdfDocument compiles and runs on Linux without 
further problems (if the makefile is ok, that is).

> > 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?

> 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?

I guess not every wxWidgets user will switch to 2.6.2 immediately. Is 
there a way to support pre 2.6.2 users?

> PS: I'm moving the thread from wxusers to wxcode since I think it's
> more relevant there. 

Right.

Thank you for your helpful responses!

Regards,

Ulrich
-- 
E-Mail privat:  Ulr...@gm...
E-Mail Studium: Ulr...@Fe...
World Wide Web: http://www.stud.fernuni-hagen.de/q1471341

Re: [wxCode-users] wxCode bakefiles for unix (was Re: ANN: wxPdfDocument 0.5 released)

[Francesco M. <f18...@ya...>]

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

Re: [wxCode-users] wxCode bakefiles for unix (was Re: ANN: wxPdfDocument 0.5 released)

[Ulrich T. <Ulr...@gm...>]

 Hi Francesco,

> usually with non-graphical components using wx I get *exactly* the
> same behaviour under all platforms;

Well, I'll keep to my habit to not promise things not confirmed to be 
working. That's the reason, I flagged wxPdfDocument for wxMSW only, 
although I'm pretty sure it should work as expected on _all_ wxWidgets 
platforms. Maybe I'm able to add wxGTK soon.

> 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.

Ok, I think I stay with the default for now.

> > 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. 

Fine.

> 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; 

Too bad. Especially for component like those on wxCode it would make 
life much easier for wxCode maintainers.

> 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.

That would be really great!

Regards,

Ulrich
-- 
E-Mail privat:  Ulr...@gm...
E-Mail Studium: Ulr...@Fe...
World Wide Web: http://www.stud.fernuni-hagen.de/q1471341