Re: conversation submodule questions

[ng0]

Schanzenbach, Martin transcribed 4.9K bytes:
> 
> 
> > On 26. Oct 2019, at 10:30, ng0 <address@hidden> wrote:
> > 
> > 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?".
> 
> That is a good point. That is probably also why gnunet currently tries to 
> build
> "as much as possible except experimental stuff".
> So that all nodes have a maximum set of compatible DHT block plugins etc.
> Not sure anymore if we should deviate from that too much ;)
> I would also like to see rest as a "base" component, actually.
> 
> This is likely a non trivial issue we want to track in a mantis issue but 
> maybe even
> address after 0.11.7.

Probably, yes.

I see a couple of perspectives we need to consider, and what our
expectations are.
The wrong builds out there are just bad work (for whatever reason,
I'm not judging and can understand not having the time to dive as
deep when the documentation can be confusing).
We can either disregard bad work or work towards avoid bad work.

One spontanious idea I just had was to track existing software dependencies
and print out a suggestion for additional switches one could activate,
in the dialogue of features probably only 5% of people read. 

I'll open a bug ticket later today, for those who still want to
comment here can do it and I'll consider comments as notes.
 
> > 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?
>