BSE update breaks SpectMorph compilation

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

BSE update breaks SpectMorph compilation

Stefan Westerfeld
   Hi!

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.

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

I wonder if I should produce fixes that replace uint8 with Bse::uint8 in
these cases.

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.

   Cu... Stefan
--
Stefan Westerfeld, http://space.twc.de/~stefan
_______________________________________________
beast mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/beast
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: BSE update breaks SpectMorph compilation

Tim Janik-6
On 30.03.2017 16:29, Stefan Westerfeld wrote:

>    Hi!
>
> 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.

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

>
>    Cu... Stefan
>

--
Yours sincerely,
Tim Janik

https://testbit.eu/timj/
Free software author.
_______________________________________________
beast mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/beast
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: BSE update breaks SpectMorph compilation

Stefan Westerfeld
   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
[hidden email]
https://mail.gnome.org/mailman/listinfo/beast
Loading...