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
_______________________________________________
beast mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/beast
