Re: Current status of OpenBSD BEAST

[Tim Janik <timj gtk org>]

On Mon, 29 Dec 2003, Nedko Arnaudov wrote:

> Tim Janik <timj@gtk.org> writes:
>
> >> > please figure what breaks upon building docs. i can't simply disable
> >> > doc generation in CVS if it's not working on your system.
> >> make in docs/generated says that it cannot find beast.1 (cannot make it)
> >> may be this is problem with my build environment.
> >
> > can you post the exact errors you're getting?
> > maybe the beast makefile setup needs some fixing, or the doc
> > build tools, i.e. texitheque, and its maintainer, alper ersoy
> > is also on this list.
>
> Making all in docs
> make[2]: Entering directory `/home/nedko/cvs/anoncvs.gnome.org/beast/docs'
> Making all in generated
> make[3]: Entering directory `/home/nedko/cvs/anoncvs.gnome.org/beast/docs/generated'
> make[4]: Entering directory `/home/nedko/cvs/anoncvs.gnome.org/beast/docs/generated'
> make[4]: *** No rule to make target `beast.1', needed by `all-am'.  Stop.
> make[4]: Leaving directory `/home/nedko/cvs/anoncvs.gnome.org/beast/docs/generated'
> make[3]: *** [all-recursive] Error 1
> make[3]: Leaving directory `/home/nedko/cvs/anoncvs.gnome.org/beast/docs/generated'
> make[2]: *** [all-recursive] Error 1
> make[2]: Leaving directory `/home/nedko/cvs/anoncvs.gnome.org/beast/docs'
> make[1]: *** [all-recursive] Error 1

your Makefile.am should contain:

# man from xml (installed)
%.1: %.1.nroff
	cp -f $< $@

so make has a build rule.

that's conditionalized on IF_BUILDDOCS, and IF_BUILDDOCS is enabled if
a) you have a proper texitheque version, and
b) you're using autogen.sh.
since configure.in if called from autogen.sh bails if it doesn't find
texitheque, you really should have that build rule, unless you manually
changed something in this chain.

> >> >> -AUTOCONF_VERSION=2.50
> >> >> +AUTOCONF_VERSION=2.58
> >> >
> >> > this affects a bunch of developers, i'd like to hear particular reasons
> >> > for upgrading the autoconf dependancy, i.e. did you make sure <2.58 breaks
> >> > for you, and if so, why?
> >>
> >> The reason is that 2.50 is not one of available OpenBSD ports.
> >> Available are 2.13 2.52 2.54 2.56 2.57
> >> Since you said that you use 2.58, I used it too.
> >> Also check for >= 2.50 is more appropriate as you said earlier.
> >> autgen.sh is too linux dependent (GNU grep) and not enough smart so may
> >> be more work needs to be done there.
> >
> > oh, didn't know. grep -q is fixed in CVS now.
>
> OpenBSD grep actually supports -q
> It does not support \b in regexps

erk. how are you guys using grep without proper regular expressions? ;)
just kidding, but \\b really is something i couldn't stand to miss
(i.e. can be kinda hard to get rid off in autogen.sh and maybe even
some makefiles).

> >> One smart thing is to make better
> >> test for versions. Checking for presence of " 1.4\b" inis not very good
> >> test for 1.4 version. First it checks it within all output. Second
> >> . means any chat withing regexps.
> >
> > erm, what check exactly do you suggest then?
> Checking for extact version like the one for libtoolize in patch I
> submited before seems more appropriate for me.

ah. that version checks for _exactly_ 1.5, while at least 1.4 should
also be ok. and it is not robust against wording changes in the output
of --version, so i'd rather see a patch that grabs the version number,
and then evals it to be >= 1.4.

> > i can't verify that libtool wants an externally set $SED,
> > in my build environment (beast/):
> >
> > $ set | fgrep SED | wc -l
> > 0
> > $ grep ^SED= *
> > aclocal.m4:SED=$lt_SED
> > aclocal.m4:SED=$lt_cv_path_SED
> > configure:SED=$lt_cv_path_SED
> > configure:SED=$lt_SED
> > libtool:SED="/bin/sed"
>
> aclocal.m4 is produced from your local m4 macros and I suspect that one
> of them sets SED in aclocal.m4 and then in configure script. This
> actually leads to broken libtool. Setting SED environment vaiable is not
> hard of course but it is starnge thing to do. More serious reason to not
> using fixed libtool is that there can be more problems that dont lead to
> unability to build beast, but to some other problem. However I am not
> aware of such problem at the moment. So if you want fixed libtool you
> should ensure that m4 macros related to it are also fixed.

hm, beast should do pretty much what glib does. can you please check
whether you get the same error when building glib from source?
or if not, what AC macros beast is missing to get your libtool to work.

> --
> Nedko Arnaudov
>

---
ciaoTJ