[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: conversation submodule questions
From: |
Schanzenbach, Martin |
Subject: |
Re: conversation submodule questions |
Date: |
Sat, 26 Oct 2019 10:41:35 +0200 |
> 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?
- conversation submodule questions, ng0, 2019/10/26
- Re: conversation submodule questions, Schanzenbach, Martin, 2019/10/26
- Re: conversation submodule questions, Christian Grothoff, 2019/10/26
- Re: conversation submodule questions, ng0, 2019/10/26
- Re: conversation submodule questions, Schanzenbach, Martin, 2019/10/26
- Re: conversation submodule questions, Christian Grothoff, 2019/10/26
- Re: conversation submodule questions, ng0, 2019/10/26
- Re: conversation submodule questions, Schanzenbach, Martin, 2019/10/26
- Re: conversation submodule questions, Christian Grothoff, 2019/10/26