couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <nsla...@apache.org>
Subject Re: make couchdb more otpish
Date Tue, 21 Jun 2011 15:59:59 GMT

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 Makefile.am)

I do not understand this argument.

No matter how you organise the source tree, files will have to be added to some Makefile.am.
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.

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


Mime
View raw message