Re: packaging beepcore-c

Well, some of the // style ocmments may relate to the documentation generator
so I am not sure it's safe to change unless you have tested that.

Building a single library is not unreasonable on the face of it, there are 
reasons to keep them separate though.  It doe make installation much easier.

I have abuild environment for beepcore-c at home, but its out of date and I need
to rebuild before I could propagate your changes into CVS.  I can perhaps think about 
it this weekend, but this week is pretty hairy for me.  Dunno if anyone else is active 
though.  Someone who has their head in teh code currently would be better.

-bill

On Mon, Jul 22, 2002 at 03:10:43PM -0700, Matt Small wrote:
> I've been looking into beepcore-c as well, and I submitted a patch to do some
> build tweaks to Huston last week.  It's available here:
> <http://users.sdsc.edu/~small/comment_inc.patch.gz>
> It changes the #include directives, and adds some more complex -I statements to
> the build system.  It also changes some comments from C++ style // to C style
> /* */ comments.  This leaves the directory structure pretty much as it is,
> which may be good or bad.
> 
> I wasn't sure what to do about the make install issue, either.  We've started
> building a single libbeepcore from all the source files, rather than trying to
> use (or link together) the library files that make install creates.
> 
> -matt
> 
> > 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
> 
> 
> -------------------------------------------------------
> 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