Re: BSE update breaks SpectMorph compilation

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) In member function ‘void SpectMorph::Encoder::approx_noise(const std::vector<float>&)’: 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.

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.

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

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

   Cu... Stefan

Yours sincerely,
Tim Janik
Free software author.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]