[PATCH] example/VFS ....confiure.in...

[Stefan (metze) Metzmacher]

At 12:48 24.06.2003 +0300, Alexander Bokovoy wrote:
>On Tue, Jun 24, 2003 at 11:35:12AM +0200, Stefan (metze) Metzmacher wrote:
> > >> Jerry, can you make sure that the VERSION string of samba matches this
> > >> parsing scheme...
> > >>
> > >> in the SAMBA_3_0 and SAMBA_2_2 branches we should have "cvs" as version
> > >> suffix
> > >> (e.g. "3.0.0beta2cvs" or "3.0.0pre3cvs" or "3.0.0rc2")
> > >>
> > >> and the SAMBA_3_0_RELEASE and SAMBA_2_2_RELEASE branches should have the
> > >> official versions.
> > >> ("3.0.0beta2" or "3.0.0rc1" or "3.0.0")
> > >I would better not make any attempt to count on particular string in
> > >VERSION as we encourage vendors to change this string to their own if they
> > >apply specific patches (regular behaviour). That means, if your logic is
> > >based on content of VERSION string, it will likely fail.
> >
> > but it should still be something like "3.0.0beta1-SuSE" ...
>Not exactly. It might be, for example, "3.0/ALT" as we do in our ALT Linux
>packages because we have continuous Samba 3.0 builds without separation on
>beta/alpha/cvs snapshot for more than 1.5 year now. Actual source code
>versioning is mentioned in the package itself.
>
> > and parsing this string is the best thing we can do for dealing with samba
> > 2.2.* and 3.0aplha* and 3.0.0beta1
>Why you need to parse that at all?

samba-vscan is using macros like:

#if (SAMBA_VERSION_MOJOR==3)

...
to able to compile with all samba 2.2.* and 3.0aplha* and 3.0.0beta1 releases

and the user had to modifiy the header file manually each time.

so I added a configure.in test for it which automaticly detect the samba 
version
and set SAMBA_VERSION_MAJOR SAMBA_VERSION_MINOR SAMBA_VERSION_RELEASE 
SAMBA_VERSION_BETA_RELEASE SAMBA_VERSION_ALPHA_RELEASE ...

this is maybe usefull for other module writers too.



metze
-----------------------------------------------------------------------------
Stefan "metze" Metzmacher <metze at metzemix.de>