gnunet-developers
[Top][All Lists]
Advanced

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

Re: conversation submodule questions


From: ng0
Subject: Re: conversation submodule questions
Date: Sat, 26 Oct 2019 08:30:35 +0000

Schanzenbach, Martin transcribed 3.0K bytes:
> 
> 
> > On 26. Oct 2019, at 10:11, ng0 <address@hidden> wrote:
> > 
> > Hi,
> > 
> > Schanzenbach, Martin transcribed 1.8K bytes:
> >> Hi,
> >> 
> >> unfortunately I would have to look into this first myself but a general 
> >> remark:
> >> 
> >> Why are we conditionally building subsystems anyway? Shouldn't we simply 
> >> have a
> >> set of subsystem which are always built and then have switches to 
> >> dis/enable others?
> >> Then, if a dependency is missing, configure should simply error.
> > 
> > This is the case right now, if you look into src/Makefile.am. There's a set 
> > of
> > "base" submodules which are build unconditionally,
> > and then we have a couple of conditional submodules
> 
> Really? I am personally responsible for making all of the REST stuff 
> conditional, i.e. it gets
> built of you have the depencies, otherwise not. My proposal would be to 
> change this into:
> 
> 1. Not build REST by default
> 2. Add an --enable-rest switch to build it
> 3. Make configure fail if dependencies are not met
> 
> And do the same to conversation, auction, consensus et al. (maybe even fs).
> That way, we can even get rid of --enable-experimental. Which is ill defined 
> anyway.
> (Who knows what is build with that switch)

Conceptually I like this idea better, it would fit into the cleanup / inventory 
check of
configure.ac I'm doing.

But in my experience people who package software most of the time do not read
the README for whatever reason (there are some who do read it). So we need a
minimal working GNUnet as we do have right now, which defines the base for
"just build it already, okay?".
Let's say this is --enable-base with a default to 1.
For the rest of the submodules and features we have to define if they
belong to base or what their own internal dependencies of enable switches
are (we have this already, but I can't remember if we documented this).

I keep my pkgsrc build already in a way which has a "base" set of features,
even removes the documentation and only adds the texi2mdoc dump, and then
adds conditionally more features.

Ideally I want to arrive at a point where it is clear what we are doing
in the configure script, do not lose track of features, can extract
shared functions to modules, and get to describe gnunet's dependencies
depending on features and not software dependencies existing describing
a set of features to be built.
 
> BR
> 
> 
> > .
> > 
> >> As it is, you never really know what the configure result will be. It 
> >> depends on the system
> >> libraries. Which is really odd.
> >> 
> >> Maybe we should change that in general in order to avoid the confusion 
> >> below?
> > 
> > Definitely, so far I skipped reading this in detail and I always thought
> > even from documentation as far as I can recall, that conversation requires
> > all 3 of the mentioned dependencies.
> > Which also made me think about adding support for the audio native to 
> > NetBSD.
> > 
> >>> On 26. Oct 2019, at 09:57, ng0 <address@hidden> wrote:
> >>> 
> >>> Good morning.
> >>> 
> >>> I have a couple of questions for building conversation.
> >>> 
> >>> 1. conversation is no longer experimental, is that true or
> >>>  was the change prior to my documentation change a mistake?
> >>> 
> >>> 2. we search for libpulse + gstreamer + libopus in the
> >>>  context of building conversation or not.
> >>>  As far as I understand it, we try to avoid pulseaudio
> >>>  in pkgsrc when possible, so my understanding right now
> >>>  while reading the checks someone wrote:
> >>> 
> >>>  -> if we have either pulse, opus, or ogg,
> >>>     -> check if we have gst and if we do,
> >>>        -> if we have conversation_backend=none
> >>>           do not build conversation (disable both
> >>>           conversation Makefile guarding conditions).
> >>>        -> else enable BUILD_GST_HELPERS
> >>>           in this case, conversation == build with gst,
> >>>           no pulseaudio required (?)
> >>>     -> check if we have conversation_backend=pulse, if so
> >>>        -> set BUILD_PULSE_HELPERS to true
> >>>           set BUILD_GST_HELPERS to false.
> >>>           in this case we don't require gst and only require
> >>>           libpulse?
> >>>     In the end we record the result conditionally in BUILD_CONVERSATION,
> >>>     which we don't use in the Makefiles so far.
> >>> 
> >>> Are the obversations above true?
> >>> 
> >> 
> 



reply via email to

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