Re: Current status of OpenBSD BEAST

[Nedko Arnaudov <nedko arnaudov atia com>]

Tim Janik <timj@gtk.org> writes:

>> make[4]: *** No rule to make target `beast.1', needed by `all-am'.  Stop.
>
> 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.

I have texitheque 0.3 and I am using autogen.sh

IF_BUILDDOCS is not enabled and this causes make to fail.

So far I've found that first time I run configure it checks for
texitheque but not second time.

I run configure script twice because I add LDFLAGS="-lpthread -lossaudio -lz"
to it after autogen.sh
This is my temporary workaround until I find why configure is not linking
these libs where/everywhere they are required.

Is running configure script twice supposed to work ?

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

Before beast I didn't know that OpenBSD grep is not GNU grep :)

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

Ok

Now when libtool is removed from CVS I'll try to build it with libtool
1.3.5p3 from OpenBSD ports system. Also I'll try autoconf 2.57 to see if
it works. This is the latest autoconf that is available from OpenBSD
ports system.

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

libtool 1.3.5p3 from OpenBSD ports (the one that ships with OpenBSD 3.4)
does not use SED so I cannot check anything. Also I guess glib
disrtibution comes libtoolized. Checkouting glib from CVS does not fit
in my current plans :)

libtool 1.5 that I installed, uses SED but defines it first.

So none of aclocal macros in my system sets SED because nobody requires
it. I guess you could search aclocal macros available in your system.

-- 
Nedko Arnaudov