couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <bchesn...@gmail.com>
Subject Re: make couchdb more otpish
Date Tue, 21 Jun 2011 16:55:20 GMT
On Tue, Jun 21, 2011 at 6:38 PM, Noah Slater <nslater@apache.org> wrote:
>
> On 21 Jun 2011, at 17:17, Benoit Chesneau wrote:
>
>> I don't buy this argument. CouchDB is an erlang application. It's true
>> that it target different kind of population and not only the
>> developer. If we consider that couchdb is an erlang application (and
>> it is really) we could just use the tools provided by this environment
>> to create release. And reltools are answering to that.
>
> I am sorry to labour the point here, but you are wrong. CouchDB isn't even a proper Erlang
application at the moment. Isn't that what this whole effort is about? Converting it to be
usable as one? I appreciate that some people want to focus on CouchDB qua an Erlang application,
but the whole project is bigger than this. That does not mean that those people are wrong
to focus on that, but we should not let this myopic view of the project start to dictate the
overall build or system integration.
>

Uh? Wer are not a proper erlang app yet (I wish we were) but it is
mostly writtent in erlang. Using the reltools doesn't make the usage
harder neither remove features. It would on the contrary conciliate
both targets and I think can provide an easy way to build a release
while being more erlangish.


>> Building a
>> release you handle the filesystem layout depending on the target
>> (system or usage), you can also handle crontab files & such. On top of
>> that you can put eventually rebar, autotools or any other packaging
>> system (like waf, scons, cmake, ...) . Have a look in the overlay
>> folder in that github repository I linked for an example.
>
> You are trivialising the effort that goes into integrating CouchDB into a full operating
system, and the work that is required to build a proper packaging and build system which works
across platforms.
>

Sorry but no. I've actually a system that work on every platform
(except for windows right now) without using autotools and
independently of the platform with all the feature (and more) we have
in couch. I'm not trivializing this effort at all. But I'm not
considering it so complicated to achieve.


>>>> Splitting in different
>>>> folders just make it harder any build we do (eg we keep forgetting
>>>> from time to time to add a file to Makefile.am)
>>>
>>> I do not understand this argument.
>>
>> In short, current system is complicated.
>
> The current system is complicated because it turns out that integrating an Erlang application
into an operating system in a way that works across many different types of systems is actually
a pretty hard thing to do. Build systems in general are extremely hard to get right. And none
of them work across as many platforms as GNU Autotools. Love it or hate it (and I'm pretty
sure we all hate it) you cannot deny that. You cannot just wish all of these problems away
by saying that it's too complex, so lets switch to something with less features, that works
for less people.
>

I'm not advocating that. I'm working to open couch for more people on
the contrary.


>> I know. Things could be a little more easier if we would generate
>> PLIST like in BSD world though.
>
> I don't understand what a PLIST is in this context.

a list of files needed to install.
>
>> Yes. Again the intention was to make the source code more friendly for
>> any erlang devs. Nothing stopyou to put in src/ if you need that and
>> i'm not against that.
>
> We are in violent agreement then.
>
>> What you does the current build system with config templates and
>> makefiles could also be done with rebar. Nothing stop you to have a
>> rebar.config file that will generated from a rebar.config.in template
>> on configure step.
>
> I agree. If we can build the Erlang application using Erlang tools, in a way that makes
THAT subcomponent of the project easy and familiar for Erlang developers, I am absolutely
behind this effort. But I want this to sit within Autotools, so that this responsibility is
"off-loaded" to rebar.
>
>>> I do not understand these proposals.
>>
>> I can't help on that.
>
> Well, you could explain them some more. :P
>
>>> I have been told many times that CouchDB is very easy to install. So much so,
in fact, that I have prided myself on that achievement. Perhaps, in another thread, you could
expand on this point.
>>
>> Well reading mails on the ml, irc, and feedback from users that's not
>> entirely true. And we speak about doing distribution for embedded
>> world current build isn't really easy to handle.
>
> Of course, we're generally only going to hear from people on the mailing list or IRC
if there has been a problem. Users don't generally post to say what an easy time they had
with the install. "Well done chaps!" But from people's blog posts about it, or in other situations
that are not focused on supporting people running in to issues, I thought that the install
system worked unusually well for this kind of project. If that is no longer the case, then
I am disappointed, and I would love to know how I can help out.
>
>> Have  alook around and you won't see any configure use in different
>> forks of couchdb.
>
> Are these forks targeting full operating system integration?
>
>

Some are yes. And this is a tangential argument. I think the
opensource project should offer the base to be built everywhere and/or
ease the work of integrators (ie not binding it to closely to any
packaging system).

- benoît

Mime
View raw message