gnunet-developers
[Top][All Lists]
Advanced

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

Re: [GNUnet-developers] building on OpenWrt with musl


From: Christian Grothoff
Subject: Re: [GNUnet-developers] building on OpenWrt with musl
Date: Sun, 21 Jun 2015 18:33:50 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.6.0

On 06/21/2015 06:17 PM, Daniel Golle wrote:
> Hi Christian,
> 
> On Sun, Jun 21, 2015 at 01:06:12PM +0200, Christian Grothoff wrote:
>> On 06/17/2015 03:35 PM, Daniel Golle wrote:
>>> Wouldn't it be possible to have autotools detect whether gnurl/curl
>>> headers are present in either possible path and set precompiler
>>> macros accordingly...?
>>>
>>
>> Code should be fixed to do this as of SVN 35963. Please let me know if
>> it doesn't work (with config.log output).
> 
> Wow, not a single out-of-tree patch left in the OpenWrt package build,
> I just removed the last dirty patch!
> https://github.com/openwrt/packages/commit/161b225acc370b9742ef3ca266be14f6cde918e9

Great, that's how it should be ;-).

> Now only these two changes needs to be discussed with and merged by the
> respective package maintainers, libmicrohttpd and libarchive which is
> used by libextractor.
> https://github.com/openwrt/packages/pull/1326
> https://github.com/openwrt/packages/pull/1447

Ok, those MHD changes are just patches against your build system,
nothing for upstream as far as I see, so I cannot help with that. But
looks straightforward enough.

> Next step would be to define meta-packages for common use-cases in
> order to have users start-off with a default pre-selection of
> libextractor plugins and gstreamer modules...
> 
> It's been great helping out packaging and cross-building GNUnet so far,
> I'm amazed by the speed the GNUnet team gets things done! Feels like
> you are just as excited about the project as if it started just
> yesterday ;)

Let's say the project has IMO gotten more and more urgent over the
years. Sadly, that doesn't mean it becomes technically easier.  But your
requirements were not that hard to fix ;-).

> I also did some homework and extended the GNUnet package to also build
> the mysql and postgresql database backends available.
> 
> I'm happy to see PostgreSQL support being quite complete as that's good
> news for performance on machines which do have more storage than RAM.
> 
> On smaller boxes (routers) I'm still dreaming about using cadet and GNS
> without needing to deploy libsqlite which is not the ideal tool when
> having only a small amount of RAM and practically no storage at all...

As I said, can be done (but not quickly, at least I don't predict having
the time), feel free to add feature requests to https://gnunet.org/bugs/

> There is one more thing I'm not sure about:
> I noticed earlier that gnunet-conversation can build against both,
> libpulse and gstreamer.
> However, the prefix for pulse cannot be passed to configure, so I
> currently work-around that by setting -Wl,rpath-link=... in
> TARGET_CLFAGS which does the job:
> https://github.com/openwrt/packages/blob/60ba8483f14c17a553ef7c3674246d9de2fdd95b/net/gnunet/Makefile#L48
> 
> Looking at the code I understand that either gstreamer OR direct
> use of libpulse, libopus and libogg can provide audio playback
> and recording.
> 
> Are both A(/V) backends equally well maintained?

I've myself only tested libpulse, IIRC gstreamer was provided for W32.
Regardless, there is not *that* much complicated code to maintain here
in the first place, so _maybe_ it doesn't matter much.

> For OpenWrt, it'd be nice to have them packaged seperately.
> Both backends equally can make sense, depending on if reuse
> of gstreamer libs by many apps justisfies its overhead.

Makes sense.

Happy hacking!

Christian

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]