Re: packaging beepcore-c

I have not been active recently on beepcore-c, but this is the right place
for this conversation.

The question of Debian packaging I think is that it would be welcome.  The guy
who did the last major revision of the build structure is Bruce Michener, and
I am not sure what his status is currenlt for spending time ome BEEP, but
he'd be the best resource for questions of the current structure of how the 
build happen.

As to include files.  There was a while ago, and it may still be an open
item, a question of some refactoring to do on the include files, to make 
things cleaner, as there were some things that we did not really like in the 
end.  As for moving to a -I compiler option rather than relative pathnames in 
#include, that's a minor change that would be welcome I think.

Not sure about the make install issues.

Huston and Marshall are probably the most active at this point I suspect.

-bill


On Fri, Jul 19, 2002 at 09:24:09PM -0400, Chris Hanson wrote:
> [I'm not sure this is the right forum for these comments.  I'm looking
> for feedback from the beepcore-c developers, and secondarily from
> other users, but there doesn't appear to be any mailing list
> specifically for discussions with the developers.  If this message is
> OT, please let me know and I'll shut up.]
> 
> I've been packaging beepcore-c 0.2 for Debian, which isn't
> straightforward since the software doesn't appear to have been
> designed to accomodate packaging.  I'd like to get my changes back
> into the upstream sources so that this and other packaging efforts are
> simplified.
> 
> There are two problems I've run into.  The first is that "make
> install" doesn't install the right things, and isn't flexible enough
> to put what it does install in the right places.  At present, I've
> worked around this by writing a custom install script, rather than
> rewriting all the makefiles.
> 
> The second problem is that the include files are all referenced using
> relative names, rather than <...>, which doesn't really work.
> Furthermore, the organization of the include files seems excessively
> complex.  It strikes me that it would be much simpler to flatten all
> that heirarchy and everywhere refer to the files using
> 
> 	<beepcore-c/FOO.h>
> 
> This will simplify the use of beepcore-c by end users, and will also
> simplify installation.
> 
> Do these sound like reasonable changes?  I'd be happy to do the edits
> and forward diffs to the developers for inclusion if desired.
> 
> ----------------
> 
> In parallel with this packaging activity, I've been playing around
> with the examples prior to using beep to build an application.  I've
> run into a problem that appears to have been seen by others: the
> beepng/beepd example pauses for arbitrary amounts of time and has very
> long round-trip times under some circumstances.
> 
> I believe this problem may be a bug in the Linux kernel. (FYI, I'm
> running Debian unstable with Linux 2.4.19-pre10, and have patched the
> kernel with RML's preempt-kernel patch.)  What I've observed is that
> the delays occur when the machine is quiescent.  If I start beepng, it
> usually hangs, but if I generate some X events, it immediately unhangs
> and finishes.  However, if I just let the machine sit there, beepng
> will hang for a long time.  I also noticed that when I was running a
> kernel compilation in the background, it didn't hang at all -- instead
> it reliably finished in reasonable amounts of time.  This behavior
> smells like a scheduler bug.
> 
> To those of you who have also seen this problem -- are you running
> Linux too?  Do you see the same symptoms?  Has anyone got more
> information?
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Beepcore-c-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/beepcore-c-users


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf