couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <>
Subject Re: make couchdb more otpish
Date Tue, 21 Jun 2011 16:06:50 GMT
On Tue, Jun 21, 2011 at 11:59 AM, Noah Slater <> wrote:
> On 21 Jun 2011, at 16:19, Benoit Chesneau wrote:
>> why not at top level? Currently everything is an src folder and I
>> don't see any reason except arbitrary concern? Why split everything in
>> folders that have not really a sense here ?
> Because there is a misconception here.
> CouchDB is not an Erlang application, and any attempt to treat it as one at this level
will cause problems. CouchDB is composed, in the main part, of an Erlang application, but
that is not the whole story. CouchDB as she is packaged at the moment is an entire system
for integrating that Erlang application into an operating system. Everything from daemon configuration,
through to log file management and man pages.
> When you look at the root of the source tree, what you are seeing is a layout for that
whole system. The main directories approximately correspond to the parts of the operating
system they touch. The only real exception is the src/ directory, which is traditionally use
to keep the sources which are compiled into the main application.
> Another way of thinking about it is this. CouchDB contains, at its heart, an Erlang application.
Some people are interested in this application sans the operating system components, and wish
to work with this as if it were a regular Erlang package. That is totally fine. But the Erlang
application is still only a (very important) subcomponent of the project, and should be kept
in a gheto, like every other part of the system.
>> 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
> I do not understand this argument.
> No matter how you organise the source tree, files will have to be added to some
These files form our contract with the release team about what should be shipped, and what
should not be shipped.
>> Anyway, apart of that, this directory structure is actually commonly
>> used in erlang world, lot of projects are using it and I don't see why
>> we couldn't too.
> I have no problem with this directory structure being used within a subdirectory that
corresponds to the Erlang application that sits at the core of the main CouchDB system. I
presume that can be done.

It can be and is what I did earlier:

>> About the vpath or so,
>> where is the real problem? We can just use rebar for what it does well
>> ie, building projects with deps and make release and use autotools to
>> detect paths and put them in Makefile and rebar config files.
> Can you expand on this?
> The problem is that if we want to use rebar as a subcomponent of the build, then it *has*
to work with VPATH builds. The only other option would be for us to maintain to concurrent
build systems. One that builds the Erlang application using Autotools, and one that uses rebar.
> Obviously, doing this would mean that we were maintaining two separate sets of instructions
for how to build the Erlang application. This obviously breaks Don't Repeat Yourself, and
will probably introduce lots of problems for us. If we get the Erlang application building
with rebar, we should want to get Autotools hooking into this properly, so that the rebar
built application is installed as part of the full CouchDB system.
>> Some notes on what I wanted to do:
>> - configure & autotools will take care about C build
>> - We can have rebar.config template overridden by ./configure.
>> - We can have reltool.config overridden in the same way which would
>> allows anyone to customize the release build like we do actually. Each
>> paths can be set in ./configure and the release will be built
>> accordingly
>> - make install will afaik install a generated release.
>> - dev will use a generated release too. no more ./utils/run hack or
>> stuff like it.
>> - deps will be present in the archive. We could keep them in deps
>> folder or just get them when we want.
> I do not understand these proposals.
> Perhaps you could go into more details about them?
>> Side note, currently couchdb build well on unix platforms (not all
>> though) but isn't really friendly to install
> 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.
>> neither to customize when you are a distributor
> I packaged CouchDB for Debian and Ubuntu, and I had no problems.
>> and really difficult to handle on mobile and embedded platforms.
> Why?

Everything else about this email is exactly what I was attempting to
communicate in a draft that I just deleted as soon as this came in.

View raw message