On Tue, Jun 21, 2011 at 6:38 PM, Noah Slater <[email protected]> wrote: > > 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. >
Uh? Wer are not a proper erlang app yet (I wish we were) but it is mostly writtent in erlang. Using the reltools doesn't make the usage harder neither remove features. It would on the contrary conciliate both targets and I think can provide an easy way to build a release while being more erlangish. >> 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. > Sorry but no. I've actually a system that work on every platform (except for windows right now) without using autotools and independently of the platform with all the feature (and more) we have in couch. I'm not trivializing this effort at all. But I'm not considering it so complicated to achieve. >>>> 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'm not advocating that. I'm working to open couch for more people on the contrary. >> 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. a list of files needed to install. > >> 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? > > Some are yes. And this is a tangential argument. I think the opensource project should offer the base to be built everywhere and/or ease the work of integrators (ie not binding it to closely to any packaging system). - benoît
