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