couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <>
Subject Re: make couchdb more otpish
Date Tue, 21 Jun 2011 16:17:49 GMT
On Tue, Jun 21, 2011 at 5:59 PM, 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.

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

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

In short, current system is complicated.

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

I know. Things could be a little more easier if we would generate
PLIST like in BSD world though.

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

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.

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

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 template
on configure step.

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

I can't help on that.
> 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.

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.

>> 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?
Have  alook around and you won't see any configure use in different
forks of couchdb.

View raw message