Re: conversation submodule questions

[Schanzenbach, Martin]

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

> 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?