Re: BSE update breaks SpectMorph compilation

[Stefan Westerfeld <stefan space twc de>]

   Hi!

On Thu, Mar 30, 2017 at 11:26:07PM +0200, Tim Janik wrote:
> On 30.03.2017 16:29, Stefan Westerfeld wrote:
> > I updated BSE, and now SpectMorph doesn't compile any more. I think there are
> > (at least) two problems:
> >
> > 1) it seems that SpectMorph code depends on types like uint64 being available
> > at global scope (which used to be the case when using libbse)
> >
> > smencoder.cc: In member function ‘void SpectMorph::Encoder::approx_noise(const std::vector<float>&)’:
> > smencoder.cc:1077:8: error: ‘uint64’ was not declared in this scope
> >    for (uint64 frame = 0; frame < audio_blocks.size(); frame++)
> >
> > This could be fixed by SpectMorph defining its own SpectMorph::uint64.
>
> Yes, I'm trying to cut down on namespace pollution.
> I.e. Bse::uint8 and Bse::uint64 should be usable and remain as such,
> as a simple workaround you can just add one line:
>
> using Bse::uint64;
>
> in your namespace.

Ok, I'll have to do this.

> Long term, Rapicorn:: symbols should *also* vanish, most of them (e.g.
> string_format) are just moving into Bse::
>
> > 2) bse headers included by SpectMorph expect undefined types
> >
> > /usr/local/beast/include/bse-0/bse/bseutils.hh:45:42: error: ‘uint8’ does not name a type
> >  Bse::Icon bse_icon_from_pixstream (const uint8 *pixstream);
>
> Odd, I'd think that should have shown up here too.
>
> > I wonder if I should produce fixes that replace uint8 with Bse::uint8 in
> > these cases.
>
> For now, a simple way for me to reproduce this would help. E.g. a short
> compilation command or somesuch, because I'm about to do more cleanups where I'm
> ideally able to run such tests to reduce fallout.

// g++ -std=gnu++11 -o x x.cc $(pkg-config --libs --cflags bse)

#include <bse/bseutils.hh>
#include <bse/bsecategories.hh>
#include <bse/bsemidievent.hh>
#include <bse/bsemididecoder.hh>
#include <bse/bsepcmwriter.hh>
#include <bse/bseexports.hh>

main()
{
}

I don't know if this covers all errors, but its a start. You could also #include just
everything from the bse directory (thats how I started to build this test case, and
later removed the files that we ok).

> > The other option for SpectMorph at this point is to replace all BSE stuff
> > (except for the Beast plugin) completely with non-BSE code. For instance data
> > handles used for reading audio files could be replaced with libsndfile and so
> > forth. This would probably be preferable from a dependency point of view, as
> > depending against libsndfile (for instance) isn't uncommon and easy for
> > packages to do, whereas depending on libbse is not as easy. And API stability
> > of libraries like libsndfile is higher, too.
> >
> > Its still quite a bit of work to completely free the codebase from libbse
> > constructs.
>
> Yeah, sorry for the hassle. Moving away is always an option if you don't have
> higher prio stuff to do. The Data handles for instance should be moved into real
> C++ objects at some point (long-long-term). That'll make them much nicer to use,
> but that'd be another API break of course.
> The bunch of migrations we've kicked off over the years (see HACKING.md) is the
> reason we're still in the 0.x.y versioning realms, and will stay there until the
> migrations are finished. Every helping hand for these efforts is of course
> appreciated ;-)

Right. I currently try to analyze and estimate how much work it would really be
to migrate away from bse...

   Cu... Stefan
-- 
Stefan Westerfeld, http://space.twc.de/~stefan