Re: Current status of OpenBSD BEAST

[Nedko Arnaudov <nedko users sourceforge net>]

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. However until I find
exact problem I decided to skip this directory. The other argument is
that 'make install'ed beast cannot run at this time anyway because it
searches its dynamic libraries in paths relative to current directory
(this is another thing that I need to solve).

>> -#include	<sys/soundcard.h>
>> +#include	<soundcard.h>
>
> this will break on linux. you actually want to add a check to configure.in
> here, and then define something like SOUNDCARD_H which can be used for these
> include statements (let it default to <sys/soundcard.h> if <soundcard.h>
> wasn't found, so things still work on linux).

Actually OSS audio is emulation layer in OpenBSD so I plan to use native
audio (or if it is not good enough make/use other API to audio
hardware). It is strange to me why Linux OSS API emulation is made in
not compatible header path. May be some time ago linux header lived in
/usr/include and was moved to /usr/include/sys later. Other possibility
is that it is in /usr/include in some Linux distribution. I cannot make
good enough check where soundcard.h lives until I find why it is where
it is. Also on other platforms soundcard.h may implement other audio API
so checking for openbsd build host may be appropriate. But it is likely
that check for BSD is the right thing because BSDs have many
shared(actually synchronized between projects) code.

>> -  if (user && 1 /* getpwnam_r check */)
>> +  if (user && 0 /* getpwnam_r check */)
>
> similar to soundcard.h, the patch here should check for getpwnam_r() in
> configure.in, and special case based on that.

I also think that this is good candidate for autoconf check. May be I'll
do it if I find common build environment with linux developers. Until
then OpenBSD developer must apply patches anyway.

>> +#include <unistd.h>
>
> can you add what warning/error you get exactly without unistd.h?
> e.g. something like: #include <unistd.h> /* for exit() */

this is required for sleep()
man 3 sleep for linux also says that unistd.h is required.
How it compiles in your build environment is mystery for me. Calling
functions without prototype ot definition is not allowed in C++ AFAIK.

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

>> -#LIBTOOL=libtool
>> +LIBTOOLIZE=libtoolize
>> +LIBTOOLIZE_VERSION=1.5
>
> i don't quite see what the point here is, CVS already has
> libtoolized files of version 1.5.

point is that libtool version in CVS assumes that SED environment
variable is set externaly which is not the case in my build
environment. May be if I used autoconf version 2.50 it will set it.

> including these files in the diff really didn't help much.
> if you meant to say that they should be removed from CVS,
> a few words would have been more appropriate than sending
> 300k of "- ..." lines.

I sent patches that worked for me. The only way to remove files by
running patch that I've found is the -N option to diff and this makes
the files so large. Next time I'll send them compressed.

>
> in any case, i'd like to hear why you did those libtool changes,
> does the CVS 1.5 version not work for you, and your 1.5 version
> does?
see above
libtool in CVS does not work for me, mine does.
Also using fixed libtool and not using fixed configure looks strange to
me. If the reqson is to minimize build trouble, from my point of view it
has opposite effect. May be this is not true for Linux developers but
AFAIK autoconf/automake/libtool suite is way to achive platform
independent software. Of course different Linux distros can also be
defined as different platforms, but they are too similar if you look
at the problem from BSD world point of view.

-- 
Nedko Arnaudov