On Tue, Jun 21, 2011 at 11:59 AM, Noah Slater <[email protected]> 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 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. >
It can be and is what I did earlier: https://github.com/davisp/couchdb-srcmv >> 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.
