You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Tristan Sloughter <tr...@gmail.com> on 2010/11/03 16:52:09 UTC
CouchDB OTP
Hi everyone, I have a github fork from apache/couchdb
https://github.com/tsloughter/couchdb that I modified to be more OTP
compliant and now builds with sinan (from http://erlware.org). There wasn't
much that I've done so far. I moved the CouchDB app under lib/couchdb. I
removed the other apps from the source tree, they can easily be installed
with faxien (from http://erlware.org) and versions can be declared if
necessary. I changed the _app.erl file to not start applications and added
those applications instead to the applications list in the .app file. They
will be started properly by the release's boot script.
I moved all non-Erlang stuff to lib/couchdb/priv.
I still have a number of things to do that I hope to get to tonight. First,
fix up the two scripts under bin/. Fix the configuration file locations
(some stuff is hardcoded for my environment). Add a hook to sinan to compile
the icu driver -- right now I just copied the library over from a build of
CouchDB I did separately.
There are probably a few other things.. But I was able to do an
application:start(couchdb) last night and see it working :).
There were a few things I thought of changing within the code as I dug
around but those are a separate issue that I'll bring up in discussion after
all this is complete.
Tristan
Re: CouchDB OTP
Posted by Jeff Zellner <je...@gmail.com>.
Hi Tristan,
Great work on OTP'izing!
I think the core team (not to speak for them, just going on what I've seen
on this list) is moving towards (or has at least discussed) rebar + OTPizing
for 1.1.0(?).
The recent thread about this kicks off here:
http://mail-archives.apache.org/mod_mbox/couchdb-dev/201010.mbox/%3CAANLkTi=HFPKeHr9KOv0GFAjgOrWqg+tETMrNz9My=3WZ@mail.gmail.com%3E
Breakdown of most of the issues from Paul Davis here:
http://mail-archives.apache.org/mod_mbox/couchdb-dev/201010.mbox/%3CAANLkTinjxrXteeG2zdGhengQy+-JoL+YxGPyrPsfN20Y@mail.gmail.com%3E
Cheers!
-Jeff
PS Also, thanks for ErlangCamp -- I had a blast and learned quite a bit --
unfortunately, didn't get to stick around in the evenings to socialise
On Wed, Nov 3, 2010 at 8:04 PM, Tristan Sloughter <
tristan.sloughter@gmail.com> wrote:
> If anyone by chance has or can easily create some simplistic make files or
> something for compiling the C code that would be AWESOME. I haven't had
> time
> to dig around what is needed to compile the different pieces but its the
> last major piece to complete.
>
> Tristan
>
> On Wed, Nov 3, 2010 at 10:52 AM, Tristan Sloughter <
> tristan.sloughter@gmail.com> wrote:
>
> > Hi everyone, I have a github fork from apache/couchdb
> > https://github.com/tsloughter/couchdb that I modified to be more OTP
> > compliant and now builds with sinan (from http://erlware.org). There
> > wasn't much that I've done so far. I moved the CouchDB app under
> > lib/couchdb. I removed the other apps from the source tree, they can
> easily
> > be installed with faxien (from http://erlware.org) and versions can be
> > declared if necessary. I changed the _app.erl file to not start
> applications
> > and added those applications instead to the applications list in the .app
> > file. They will be started properly by the release's boot script.
> >
> > I moved all non-Erlang stuff to lib/couchdb/priv.
> >
> > I still have a number of things to do that I hope to get to tonight.
> First,
> > fix up the two scripts under bin/. Fix the configuration file locations
> > (some stuff is hardcoded for my environment). Add a hook to sinan to
> compile
> > the icu driver -- right now I just copied the library over from a build
> of
> > CouchDB I did separately.
> >
> > There are probably a few other things.. But I was able to do an
> > application:start(couchdb) last night and see it working :).
> >
> > There were a few things I thought of changing within the code as I dug
> > around but those are a separate issue that I'll bring up in discussion
> after
> > all this is complete.
> >
> > Tristan
> >
>
Re: CouchDB OTP
Posted by Tristan Sloughter <tr...@gmail.com>.
P.S. Glad you enjoyed ErlangCamp :). Sucks you didn't make the night events,
they were great. Maybe next time!
On Wed, Nov 3, 2010 at 7:39 PM, Tristan Sloughter <
tristan.sloughter@gmail.com> wrote:
> I see it was already discussed about breaking CouchDB into apps:
>
> couch_core: The core Erlang modules for storing docs and managing "internal infrastructure"
> couch_view: The view engine as well as the holder for managing OS processes.
> couch_rep: couch_rep*.erl
> couch_externals: couch_external*.erl
> couch_httpd: couch_http*.erl
>
> I was going to also start on that after getting the build stable. Now I see
> the work of deciding what goes where was already done :).
>
> This is great. I hope my work on this can be helpful for the move in 1.1.x
> you guys want to make.
>
> Tristan
>
> On Wed, Nov 3, 2010 at 7:33 PM, Tristan Sloughter <
> tristan.sloughter@gmail.com> wrote:
>
>> Hmm, ok. I have replaced the build system. I am using sinan but it should
>> be buildable now with any Erlang/OTP build tool, like rebar. I am just
>> running it as a release from a script that erl-execs the boot file.
>>
>> What complex stuff is the build system dealing with? I'm separating the
>> config file (and similar files) problem and the icu and couch_js problem. I
>> was hoping building those few C files wouldn't be bad, but I guess that is
>> not true from what you are saying?
>>
>> I'd still say it should be autotools, or whatever, inside an Erlang build
>> system.
>>
>> Tristan
>>
>>
>> On Wed, Nov 3, 2010 at 7:28 PM, Noah Slater <ns...@apache.org> wrote:
>>
>>> Have you wholesale replaced the existing build system?
>>>
>>> If you have, it's going to be a tad more complex than knocking up a few
>>> makefiles to compile C. There's lots of very complex stuff our build system
>>> copes with at the moment. I'm not convinced it can be replaced by an Erlang
>>> build system and a few shell scripts. We've had chats about improving the
>>> build system before, and I think the consensus is that we wrap an Erlang
>>> build system WITHIN the Autotools system.
>>>
>>> What are you thoughts?
>>>
>>> On 4 Nov 2010, at 00:04, Tristan Sloughter wrote:
>>>
>>> > If anyone by chance has or can easily create some simplistic make files
>>> or
>>> > something for compiling the C code that would be AWESOME. I haven't had
>>> time
>>> > to dig around what is needed to compile the different pieces but its
>>> the
>>> > last major piece to complete.
>>> >
>>> > Tristan
>>> >
>>> > On Wed, Nov 3, 2010 at 10:52 AM, Tristan Sloughter <
>>> > tristan.sloughter@gmail.com> wrote:
>>> >
>>> >> Hi everyone, I have a github fork from apache/couchdb
>>> >> https://github.com/tsloughter/couchdb that I modified to be more OTP
>>> >> compliant and now builds with sinan (from http://erlware.org). There
>>> >> wasn't much that I've done so far. I moved the CouchDB app under
>>> >> lib/couchdb. I removed the other apps from the source tree, they can
>>> easily
>>> >> be installed with faxien (from http://erlware.org) and versions can
>>> be
>>> >> declared if necessary. I changed the _app.erl file to not start
>>> applications
>>> >> and added those applications instead to the applications list in the
>>> .app
>>> >> file. They will be started properly by the release's boot script.
>>> >>
>>> >> I moved all non-Erlang stuff to lib/couchdb/priv.
>>> >>
>>> >> I still have a number of things to do that I hope to get to tonight.
>>> First,
>>> >> fix up the two scripts under bin/. Fix the configuration file
>>> locations
>>> >> (some stuff is hardcoded for my environment). Add a hook to sinan to
>>> compile
>>> >> the icu driver -- right now I just copied the library over from a
>>> build of
>>> >> CouchDB I did separately.
>>> >>
>>> >> There are probably a few other things.. But I was able to do an
>>> >> application:start(couchdb) last night and see it working :).
>>> >>
>>> >> There were a few things I thought of changing within the code as I dug
>>> >> around but those are a separate issue that I'll bring up in discussion
>>> after
>>> >> all this is complete.
>>> >>
>>> >> Tristan
>>> >>
>>>
>>>
>>
>
Re: CouchDB OTP
Posted by Tristan Sloughter <tr...@gmail.com>.
I see it was already discussed about breaking CouchDB into apps:
couch_core: The core Erlang modules for storing docs and managing
"internal infrastructure"
couch_view: The view engine as well as the holder for managing OS processes.
couch_rep: couch_rep*.erl
couch_externals: couch_external*.erl
couch_httpd: couch_http*.erl
I was going to also start on that after getting the build stable. Now I see
the work of deciding what goes where was already done :).
This is great. I hope my work on this can be helpful for the move in 1.1.x
you guys want to make.
Tristan
On Wed, Nov 3, 2010 at 7:33 PM, Tristan Sloughter <
tristan.sloughter@gmail.com> wrote:
> Hmm, ok. I have replaced the build system. I am using sinan but it should
> be buildable now with any Erlang/OTP build tool, like rebar. I am just
> running it as a release from a script that erl-execs the boot file.
>
> What complex stuff is the build system dealing with? I'm separating the
> config file (and similar files) problem and the icu and couch_js problem. I
> was hoping building those few C files wouldn't be bad, but I guess that is
> not true from what you are saying?
>
> I'd still say it should be autotools, or whatever, inside an Erlang build
> system.
>
> Tristan
>
>
> On Wed, Nov 3, 2010 at 7:28 PM, Noah Slater <ns...@apache.org> wrote:
>
>> Have you wholesale replaced the existing build system?
>>
>> If you have, it's going to be a tad more complex than knocking up a few
>> makefiles to compile C. There's lots of very complex stuff our build system
>> copes with at the moment. I'm not convinced it can be replaced by an Erlang
>> build system and a few shell scripts. We've had chats about improving the
>> build system before, and I think the consensus is that we wrap an Erlang
>> build system WITHIN the Autotools system.
>>
>> What are you thoughts?
>>
>> On 4 Nov 2010, at 00:04, Tristan Sloughter wrote:
>>
>> > If anyone by chance has or can easily create some simplistic make files
>> or
>> > something for compiling the C code that would be AWESOME. I haven't had
>> time
>> > to dig around what is needed to compile the different pieces but its the
>> > last major piece to complete.
>> >
>> > Tristan
>> >
>> > On Wed, Nov 3, 2010 at 10:52 AM, Tristan Sloughter <
>> > tristan.sloughter@gmail.com> wrote:
>> >
>> >> Hi everyone, I have a github fork from apache/couchdb
>> >> https://github.com/tsloughter/couchdb that I modified to be more OTP
>> >> compliant and now builds with sinan (from http://erlware.org). There
>> >> wasn't much that I've done so far. I moved the CouchDB app under
>> >> lib/couchdb. I removed the other apps from the source tree, they can
>> easily
>> >> be installed with faxien (from http://erlware.org) and versions can be
>> >> declared if necessary. I changed the _app.erl file to not start
>> applications
>> >> and added those applications instead to the applications list in the
>> .app
>> >> file. They will be started properly by the release's boot script.
>> >>
>> >> I moved all non-Erlang stuff to lib/couchdb/priv.
>> >>
>> >> I still have a number of things to do that I hope to get to tonight.
>> First,
>> >> fix up the two scripts under bin/. Fix the configuration file locations
>> >> (some stuff is hardcoded for my environment). Add a hook to sinan to
>> compile
>> >> the icu driver -- right now I just copied the library over from a build
>> of
>> >> CouchDB I did separately.
>> >>
>> >> There are probably a few other things.. But I was able to do an
>> >> application:start(couchdb) last night and see it working :).
>> >>
>> >> There were a few things I thought of changing within the code as I dug
>> >> around but those are a separate issue that I'll bring up in discussion
>> after
>> >> all this is complete.
>> >>
>> >> Tristan
>> >>
>>
>>
>
Re: CouchDB OTP
Posted by Paul Davis <pa...@gmail.com>.
On Thu, Nov 4, 2010 at 12:49 AM, Noah Slater <ns...@apache.org> wrote:
>
> On 4 Nov 2010, at 04:41, Paul Davis wrote:
>
>> The issue with configure.ac is that it is a pre-distribution method
>> for configuring a build system. As in, if we claim some functionality
>> for Erlang builds via configure.ac, then we're tacitly making the
>> claim that we'll have multiple distributions, a "rebar distribution"
>> and a "erlc distribution". Its not unfathomable to me that we just say
>> "tarballs will use erlc" which is not out of the question, but it
>> still seems weird.
>
> Nu, uh...
>
> `./configure` is run during every local install.
>
> What I described is possible for every single individual user.
>
Oh right. For some reason I was thinking you were saying to put the
"erlc vs rebar" decision in configure.ac instead of "generate the
logic to decide when ./configure is run." Hence why you are sempi.
>> The other issue is that I do realize that we can leverage ./configure
>> to (for lack of alternate verb) configure the build. The issue with
>> rebar and VPATH builds is that reading the docs and source code, I
>> could not see any method to tell rebar "your source files are in this
>> place, place your output in this other place." As I read rebar's
>> source, its output paths are absolutely defined by the input file
>> name. I'm guessing that Noah is incredulous by this claim, but I will
>> remind him that rebar is awesome precisely because of this sort of
>> prejudice, its just not VPATH aware.
>
> So, it's output files are in predictable locations?
>
> Sounds like a good opportunity for post-hoc installation logic. :)
>
> Either way, I see it like this:
>
> - Before build time we can control what rebar sees.
>
> - After build time, we can modify and move files as we want.
>
> What more could you possibly ask for?
>
> Except for the problem to go away entirely, of course. :)
>
Quite predictable locations. But the way we would predict what goes
where would basically be to copy portions of the source tree to the
build tree before invoking rebar. Its not out of the question, but
seems "not quite right".
>> Also, writable source trees. I know Noah knows this, but people that
>> aren't familiar with VPATH often get tripped up on this. The key thing
>> that made this click for me was to imagine expanding a tarball,
>> writing the source code to a CD, and then building and installing from
>> that CD without copying source files.
>
> Good catch, I forget to mention a lot of this stuff. :)
>
>> I think that's the right sentiment, but slightly not quite right I
>> think. The analogy I would use would be more like, "Reconciling Erlang
>> builds with Autotools builds is like trying to translate poetry from
>> Turkish to Navajo."
>
> Actually, I think it should be perfectly surmountable. The key will be in separating the Erlang build from the main build. Think of it like compiling a C app. You wouldn't have the compiler try to move the files into location, or handle the installation of the /etc/config/file. So, just treat rebar, or whatever, as the compilation step for an OTP app (even though the result is a directory tree, a bit like NeXT really) and use Autotools to plop that into the right location on the filesystem.
Exactly. I think its quite possible, I just don't speak Autofu as
fluently as you to know what the "elegant" solution would be here. My
concern is if our 'surmounting effort' turns into a "'oh fuck, that
doesn't work on Solaris 3.3 when running on a Sparc Ultra2400 with the
32GiB RAM expansion while PXE booting off a Broadcom 802.11k chipset.'
effort". I'm just saying...
HTH,
Paul Davis
Re: CouchDB OTP
Posted by Noah Slater <ns...@apache.org>.
On 4 Nov 2010, at 04:41, Paul Davis wrote:
> The issue with configure.ac is that it is a pre-distribution method
> for configuring a build system. As in, if we claim some functionality
> for Erlang builds via configure.ac, then we're tacitly making the
> claim that we'll have multiple distributions, a "rebar distribution"
> and a "erlc distribution". Its not unfathomable to me that we just say
> "tarballs will use erlc" which is not out of the question, but it
> still seems weird.
Nu, uh...
`./configure` is run during every local install.
What I described is possible for every single individual user.
> The other issue is that I do realize that we can leverage ./configure
> to (for lack of alternate verb) configure the build. The issue with
> rebar and VPATH builds is that reading the docs and source code, I
> could not see any method to tell rebar "your source files are in this
> place, place your output in this other place." As I read rebar's
> source, its output paths are absolutely defined by the input file
> name. I'm guessing that Noah is incredulous by this claim, but I will
> remind him that rebar is awesome precisely because of this sort of
> prejudice, its just not VPATH aware.
So, it's output files are in predictable locations?
Sounds like a good opportunity for post-hoc installation logic. :)
Either way, I see it like this:
- Before build time we can control what rebar sees.
- After build time, we can modify and move files as we want.
What more could you possibly ask for?
Except for the problem to go away entirely, of course. :)
> Also, writable source trees. I know Noah knows this, but people that
> aren't familiar with VPATH often get tripped up on this. The key thing
> that made this click for me was to imagine expanding a tarball,
> writing the source code to a CD, and then building and installing from
> that CD without copying source files.
Good catch, I forget to mention a lot of this stuff. :)
> I think that's the right sentiment, but slightly not quite right I
> think. The analogy I would use would be more like, "Reconciling Erlang
> builds with Autotools builds is like trying to translate poetry from
> Turkish to Navajo."
Actually, I think it should be perfectly surmountable. The key will be in separating the Erlang build from the main build. Think of it like compiling a C app. You wouldn't have the compiler try to move the files into location, or handle the installation of the /etc/config/file. So, just treat rebar, or whatever, as the compilation step for an OTP app (even though the result is a directory tree, a bit like NeXT really) and use Autotools to plop that into the right location on the filesystem.
Re: CouchDB OTP
Posted by Paul Davis <pa...@gmail.com>.
On Wed, Nov 3, 2010 at 11:53 PM, Noah Slater <ns...@apache.org> wrote:
>
> On 4 Nov 2010, at 03:27, Paul Davis wrote:
>
>> 1. We have constraints. Noah's pointed out a few, but I don't even
>> think that list is exhaustive. A project like CouchDB needs to pay
>> attention to a lot of different details. I've said before that Noah is
>> the Chuck Norris of Autotools, so any proposed changes will need to be
>> cleared by him. He is the de facto BDFL for our build system and I
>> will vote with him lock step on any proposal.
>>
>> 2. There are lots of things in our current build system that may seem
>> innocuous at first, but turn out to be A Big Deal in some specific
>> circumstances that aren't always apparent at first glance.
>>
>> 3. A lot of changes I see in your CouchDB branch aren't going to fly.
>> Some reasons may seem trivial but this is me relying on knowledge from
>> Noah Chuck Norris Slater.
>
> I love this mailing list. *g*
>
>> 4. I'm not sure about Sinan, but rebar won't work out of the box for a
>> default build tool because of a lack of support for VPATH builds. At
>> this moment I'm still concentrating on making sure we can do a full
>> rebar build to support things like Erlang releases, but it's been
>> de-prioritized to a "secondary build system" status. If Sinan can do
>> VPATH builds, then I think it'd be a very good thing to support.
>>
>> 5. Erlang build knowledge is at some level, incompatible with
>> Autotools build knowledge. We need to find a common ground and figure
>> out where we can compromise to hopefully make both work. My current
>> shimmering of an idea for rebar was to have a make target that was
>> something like "make rebar" which would short circuit some parts of a
>> default build with rebar. Its possible that we can revamp part of the
>> build system to overcome the constraints of Autotools, but as I see it
>> the first move might just make a "developer friendly" alternate build
>> style.
>
> I'm not sure if I've mentioned this before, but I see a way forward with this. I'm going to assume that you (Paul, specifically here) know enough about Autotools to be familiar with the role that configure.ac plays in the whole process.
>
> To break it down for you:
>
> - `./configure` preps the source tree for build-specific rules
>
> - `make` preps the files needed to install
>
> - `make` install installs the files
>
> A key to realising the power of this is in considering what you can do with the configure.ac script, which in turns is "compiled" down to the configure script the user runs. For example, you can ALTER the build process during `make` by having configure.ac modify or write out customised files.
>
> So, as far as I see it, making rebar VPATH compatible should be as simple as creating the rebar spec file (to make up some terminology - whatever it is that tells rebar how to build stuff) during the `./configure` step. Presumably, by writing files, or even replacing text within files.
>
> You've seen the @variables@ in some locations, Paul? They're things that we replace during the `./configure` step. Nothing stopping you from using a @PREFIX@ type variable for the file that is ultimately used during the `make` step.
>
I preface with this with the fact that I do not wish to know the wrath
of a Chuck Norris round house kick the face.
The issue with configure.ac is that it is a pre-distribution method
for configuring a build system. As in, if we claim some functionality
for Erlang builds via configure.ac, then we're tacitly making the
claim that we'll have multiple distributions, a "rebar distribution"
and a "erlc distribution". Its not unfathomable to me that we just say
"tarballs will use erlc" which is not out of the question, but it
still seems weird.
The other issue is that I do realize that we can leverage ./configure
to (for lack of alternate verb) configure the build. The issue with
rebar and VPATH builds is that reading the docs and source code, I
could not see any method to tell rebar "your source files are in this
place, place your output in this other place." As I read rebar's
source, its output paths are absolutely defined by the input file
name. I'm guessing that Noah is incredulous by this claim, but I will
remind him that rebar is awesome precisely because of this sort of
prejudice, its just not VPATH aware.
>> 7. Removing dependencies from the source tree is not going to happen
>> any time soon. I wish we didn't have to vendor so many projects, but
>> we have to remember that a majority of people building CouchDB are not
>> Erlangians. Forcing our community to install a number of Erlang
>> dependencies to build CouchDB would be a very large hurdle to
>> navigate. I know that there are projects like faxien and rebar's git
>> support to overcome this, but I don't feel that there is a solution
>> that sufficiently addresses this issue.
>
> And doing it at build time breaks a really fundamental rule of build systems.
>
> Never assume a network connection
>
Also, writable source trees. I know Noah knows this, but people that
aren't familiar with VPATH often get tripped up on this. The key thing
that made this click for me was to imagine expanding a tarball,
writing the source code to a CD, and then building and installing from
that CD without copying source files.
>> 8. I don't know about Sinan or Rebar's platform support specifically.
>> Building C code portably is very very hard. I know that people detest
>> Autotools for such things, but its got an uncountable number of man
>> years addressing platform specific build issues. I don't think its
>> impossible to replace for building C code, I just see it as staring at
>> a mountain when people suggest it. IIRC, one of my first conversations
>> with Noah was switching to SCons. As much as it pains me now to admit,
>> I'm glad at he laughed at me then.
>
> I'm going to quote Mark Pilgrim on this:
>
> 'Here’s the basic problem: you’re writing a text editor. Stop doing that. It’s 2007. Saying to yourself “I’m gonna build my own text editor” is as silly as saying “I’m gonna build my own build system” or “I’m gonna build my own amusement park.” Blackjack and hookers and all that. Writing a great text editor is insanely difficult. There is a certain class of software that sounds easy but is actually insanely difficult. I call it “garden path software.” If I ever start a software company, I’ll name it “Garden Path Software,” but until then, just stop.'
>
> Autotools is a big, stinking, POS — but it gets the job done, precisely because it's been around for 20 years. [1] This software has been tested on and ported to so many systems, it would make your mind boggle. If you're distributing source packages to a large user-base, especially with C code, there are very few sensible alternatives.
>
> [1] http://www.gnu.org/software/autoconf/manual/autoconf.html#History
>
>
>
I think that's the right sentiment, but slightly not quite right I
think. The analogy I would use would be more like, "Reconciling Erlang
builds with Autotools builds is like trying to translate poetry from
Turkish to Navajo."
To put things into perspective, http://bit.ly/aOVPKv
HTH,
Paul Davis
Re: CouchDB OTP
Posted by Noah Slater <ns...@apache.org>.
Tristan,
I am totally re-surfacing a two year old thread.
Just to let you know that we're abandoning Autotools in favour of rebar.
Benoit is the guy to speak to, if you're still interested in contributing
to this part of CouchDB.
I believe he plans to have a branch set up in the next week, ready to pull
over some of the work he's been doing on rcouch.
On 4 November 2010 16:03, Tristan Sloughter <tr...@gmail.com>wrote:
> Great. And I'd be more than happy to act as a sounding board.
>
> Tristan
>
> On Thu, Nov 4, 2010 at 10:26 AM, Paul Davis <paul.joseph.davis@gmail.com
> >wrote:
>
> > On Thu, Nov 4, 2010 at 11:07 AM, Tristan Sloughter
> > <tr...@gmail.com> wrote:
> > > This is a great discussion and I want it to keep going. But I'm going
> to
> > try
> > > to lay out how I plan to move forward and hopefully this will help in
> the
> > > future.
> > >
> > > I'm going to use autotools for building only the C pieces and not for
> > > anything else. I want to be able to use this as a normal release/target
> > > system afterwards installed like any other. So I don't want to use
> > something
> > > for placing config files or whatever. I know that won't mold well with
> > the
> > > normal CouchDB use-case but maybe its simple to do both... Or I'll
> > realize
> > > thats futile and do something with setting where configs live through
> > > sys.config when its passed to erlexec...
> > >
> >
> > I haven't yet spent much time contemplating how these bits are going
> > to interact. I'll be very interested to see how you approach things
> > here to make things work with Rebar and Sinan.
> >
> > > Anyway, I'd hope my fork could be seen as a testbed of sorts. As I
> said,
> > it
> > > should be buildable with rebar as well.
> > >
> >
> > Having an example on how the code looks using Sinan or Rebar will be
> > an awesome start as I begin digging into how some of the unexciting
> > parts of the build. I'll be watching your repo as you hack there and
> > if you don't mind I plan on using you as a sounding board while I
> > puzzle through these different parts.
> >
> > Paul Davis
> >
>
--
NS
Re: CouchDB OTP
Posted by Tristan Sloughter <tr...@gmail.com>.
Great. And I'd be more than happy to act as a sounding board.
Tristan
On Thu, Nov 4, 2010 at 10:26 AM, Paul Davis <pa...@gmail.com>wrote:
> On Thu, Nov 4, 2010 at 11:07 AM, Tristan Sloughter
> <tr...@gmail.com> wrote:
> > This is a great discussion and I want it to keep going. But I'm going to
> try
> > to lay out how I plan to move forward and hopefully this will help in the
> > future.
> >
> > I'm going to use autotools for building only the C pieces and not for
> > anything else. I want to be able to use this as a normal release/target
> > system afterwards installed like any other. So I don't want to use
> something
> > for placing config files or whatever. I know that won't mold well with
> the
> > normal CouchDB use-case but maybe its simple to do both... Or I'll
> realize
> > thats futile and do something with setting where configs live through
> > sys.config when its passed to erlexec...
> >
>
> I haven't yet spent much time contemplating how these bits are going
> to interact. I'll be very interested to see how you approach things
> here to make things work with Rebar and Sinan.
>
> > Anyway, I'd hope my fork could be seen as a testbed of sorts. As I said,
> it
> > should be buildable with rebar as well.
> >
>
> Having an example on how the code looks using Sinan or Rebar will be
> an awesome start as I begin digging into how some of the unexciting
> parts of the build. I'll be watching your repo as you hack there and
> if you don't mind I plan on using you as a sounding board while I
> puzzle through these different parts.
>
> Paul Davis
>
Re: CouchDB OTP
Posted by Paul Davis <pa...@gmail.com>.
On Thu, Nov 4, 2010 at 11:07 AM, Tristan Sloughter
<tr...@gmail.com> wrote:
> This is a great discussion and I want it to keep going. But I'm going to try
> to lay out how I plan to move forward and hopefully this will help in the
> future.
>
> I'm going to use autotools for building only the C pieces and not for
> anything else. I want to be able to use this as a normal release/target
> system afterwards installed like any other. So I don't want to use something
> for placing config files or whatever. I know that won't mold well with the
> normal CouchDB use-case but maybe its simple to do both... Or I'll realize
> thats futile and do something with setting where configs live through
> sys.config when its passed to erlexec...
>
I haven't yet spent much time contemplating how these bits are going
to interact. I'll be very interested to see how you approach things
here to make things work with Rebar and Sinan.
> Anyway, I'd hope my fork could be seen as a testbed of sorts. As I said, it
> should be buildable with rebar as well.
>
Having an example on how the code looks using Sinan or Rebar will be
an awesome start as I begin digging into how some of the unexciting
parts of the build. I'll be watching your repo as you hack there and
if you don't mind I plan on using you as a sounding board while I
puzzle through these different parts.
Paul Davis
Re: CouchDB OTP
Posted by Tristan Sloughter <tr...@gmail.com>.
This is a great discussion and I want it to keep going. But I'm going to try
to lay out how I plan to move forward and hopefully this will help in the
future.
I'm going to use autotools for building only the C pieces and not for
anything else. I want to be able to use this as a normal release/target
system afterwards installed like any other. So I don't want to use something
for placing config files or whatever. I know that won't mold well with the
normal CouchDB use-case but maybe its simple to do both... Or I'll realize
thats futile and do something with setting where configs live through
sys.config when its passed to erlexec...
Anyway, I'd hope my fork could be seen as a testbed of sorts. As I said, it
should be buildable with rebar as well.
Tristan
On Wed, Nov 3, 2010 at 11:04 PM, Noah Slater <ns...@echolibre.com> wrote:
>
> On 4 Nov 2010, at 03:53, Noah Slater wrote:
>
> > Autotools is a big, stinking, POS — but it gets the job done, precisely
> because it's been around for 20 years. [1] This software has been tested on
> and ported to so many systems, it would make your mind boggle. If you're
> distributing source packages to a large user-base, especially with C code,
> there are very few sensible alternatives.
>
> Something occurred to me after sending this email. I wrote the CouchDB
> build system three years ago now. The only major changes I've ever made to
> it since then have been additions for new pieces of CouchDB proper. The
> amount of bugs that are found in it are minimal, to say the least. They say
> that data matures like wine, and software matures like fish — but it's been
> one of the most enduring bits of code I've probably ever produced. And I
> credit that entirely to the Autotools maintainers. Hehe.
>
>
Re: CouchDB OTP
Posted by Noah Slater <ns...@echolibre.com>.
On 4 Nov 2010, at 03:53, Noah Slater wrote:
> Autotools is a big, stinking, POS — but it gets the job done, precisely because it's been around for 20 years. [1] This software has been tested on and ported to so many systems, it would make your mind boggle. If you're distributing source packages to a large user-base, especially with C code, there are very few sensible alternatives.
Something occurred to me after sending this email. I wrote the CouchDB build system three years ago now. The only major changes I've ever made to it since then have been additions for new pieces of CouchDB proper. The amount of bugs that are found in it are minimal, to say the least. They say that data matures like wine, and software matures like fish — but it's been one of the most enduring bits of code I've probably ever produced. And I credit that entirely to the Autotools maintainers. Hehe.
Re: CouchDB OTP
Posted by Paul Davis <pa...@gmail.com>.
On Thu, Nov 4, 2010 at 7:40 AM, Adam Kocoloski <ko...@apache.org> wrote:
> On Nov 3, 2010, at 11:53 PM, Noah Slater wrote:
>
>>> 7. Removing dependencies from the source tree is not going to happen
>>> any time soon. I wish we didn't have to vendor so many projects, but
>>> we have to remember that a majority of people building CouchDB are not
>>> Erlangians. Forcing our community to install a number of Erlang
>>> dependencies to build CouchDB would be a very large hurdle to
>>> navigate. I know that there are projects like faxien and rebar's git
>>> support to overcome this, but I don't feel that there is a solution
>>> that sufficiently addresses this issue.
>>
>> And doing it at build time breaks a really fundamental rule of build systems.
>>
>> Never assume a network connection
>
> Can we remove the dependencies from the repository but include them in all release tarballs? For example, in a rebar world we would call 'get-deps' in the course of building a release tarball. Throwing away the commit history of our upstream dependencies makes regression-hunting more difficult than it needs to be.
>
> Adam
I'm not entirely against this approach at first glance. Though the
thing that comes to mind is how the ASF would view building release
artifacts with this much code that's not in SVN. I'll ping infra to
see if they have prior experience.
Paul
Re: CouchDB OTP
Posted by Adam Kocoloski <ko...@apache.org>.
On Nov 3, 2010, at 11:53 PM, Noah Slater wrote:
>> 7. Removing dependencies from the source tree is not going to happen
>> any time soon. I wish we didn't have to vendor so many projects, but
>> we have to remember that a majority of people building CouchDB are not
>> Erlangians. Forcing our community to install a number of Erlang
>> dependencies to build CouchDB would be a very large hurdle to
>> navigate. I know that there are projects like faxien and rebar's git
>> support to overcome this, but I don't feel that there is a solution
>> that sufficiently addresses this issue.
>
> And doing it at build time breaks a really fundamental rule of build systems.
>
> Never assume a network connection
Can we remove the dependencies from the repository but include them in all release tarballs? For example, in a rebar world we would call 'get-deps' in the course of building a release tarball. Throwing away the commit history of our upstream dependencies makes regression-hunting more difficult than it needs to be.
Adam
Re: CouchDB OTP
Posted by Noah Slater <ns...@apache.org>.
On 4 Nov 2010, at 03:27, Paul Davis wrote:
> 1. We have constraints. Noah's pointed out a few, but I don't even
> think that list is exhaustive. A project like CouchDB needs to pay
> attention to a lot of different details. I've said before that Noah is
> the Chuck Norris of Autotools, so any proposed changes will need to be
> cleared by him. He is the de facto BDFL for our build system and I
> will vote with him lock step on any proposal.
>
> 2. There are lots of things in our current build system that may seem
> innocuous at first, but turn out to be A Big Deal in some specific
> circumstances that aren't always apparent at first glance.
>
> 3. A lot of changes I see in your CouchDB branch aren't going to fly.
> Some reasons may seem trivial but this is me relying on knowledge from
> Noah Chuck Norris Slater.
I love this mailing list. *g*
> 4. I'm not sure about Sinan, but rebar won't work out of the box for a
> default build tool because of a lack of support for VPATH builds. At
> this moment I'm still concentrating on making sure we can do a full
> rebar build to support things like Erlang releases, but it's been
> de-prioritized to a "secondary build system" status. If Sinan can do
> VPATH builds, then I think it'd be a very good thing to support.
>
> 5. Erlang build knowledge is at some level, incompatible with
> Autotools build knowledge. We need to find a common ground and figure
> out where we can compromise to hopefully make both work. My current
> shimmering of an idea for rebar was to have a make target that was
> something like "make rebar" which would short circuit some parts of a
> default build with rebar. Its possible that we can revamp part of the
> build system to overcome the constraints of Autotools, but as I see it
> the first move might just make a "developer friendly" alternate build
> style.
I'm not sure if I've mentioned this before, but I see a way forward with this. I'm going to assume that you (Paul, specifically here) know enough about Autotools to be familiar with the role that configure.ac plays in the whole process.
To break it down for you:
- `./configure` preps the source tree for build-specific rules
- `make` preps the files needed to install
- `make` install installs the files
A key to realising the power of this is in considering what you can do with the configure.ac script, which in turns is "compiled" down to the configure script the user runs. For example, you can ALTER the build process during `make` by having configure.ac modify or write out customised files.
So, as far as I see it, making rebar VPATH compatible should be as simple as creating the rebar spec file (to make up some terminology - whatever it is that tells rebar how to build stuff) during the `./configure` step. Presumably, by writing files, or even replacing text within files.
You've seen the @variables@ in some locations, Paul? They're things that we replace during the `./configure` step. Nothing stopping you from using a @PREFIX@ type variable for the file that is ultimately used during the `make` step.
> 7. Removing dependencies from the source tree is not going to happen
> any time soon. I wish we didn't have to vendor so many projects, but
> we have to remember that a majority of people building CouchDB are not
> Erlangians. Forcing our community to install a number of Erlang
> dependencies to build CouchDB would be a very large hurdle to
> navigate. I know that there are projects like faxien and rebar's git
> support to overcome this, but I don't feel that there is a solution
> that sufficiently addresses this issue.
And doing it at build time breaks a really fundamental rule of build systems.
Never assume a network connection
> 8. I don't know about Sinan or Rebar's platform support specifically.
> Building C code portably is very very hard. I know that people detest
> Autotools for such things, but its got an uncountable number of man
> years addressing platform specific build issues. I don't think its
> impossible to replace for building C code, I just see it as staring at
> a mountain when people suggest it. IIRC, one of my first conversations
> with Noah was switching to SCons. As much as it pains me now to admit,
> I'm glad at he laughed at me then.
I'm going to quote Mark Pilgrim on this:
'Here’s the basic problem: you’re writing a text editor. Stop doing that. It’s 2007. Saying to yourself “I’m gonna build my own text editor” is as silly as saying “I’m gonna build my own build system” or “I’m gonna build my own amusement park.” Blackjack and hookers and all that. Writing a great text editor is insanely difficult. There is a certain class of software that sounds easy but is actually insanely difficult. I call it “garden path software.” If I ever start a software company, I’ll name it “Garden Path Software,” but until then, just stop.'
Autotools is a big, stinking, POS — but it gets the job done, precisely because it's been around for 20 years. [1] This software has been tested on and ported to so many systems, it would make your mind boggle. If you're distributing source packages to a large user-base, especially with C code, there are very few sensible alternatives.
[1] http://www.gnu.org/software/autoconf/manual/autoconf.html#History
Re: CouchDB OTP
Posted by Paul Davis <pa...@gmail.com>.
On Wed, Nov 3, 2010 at 8:45 PM, Tristan Sloughter
<tr...@gmail.com> wrote:
> Agreed. That sounds like a good plan. I'd just want to ensure that the
> Erlang side can be installed as a release and run as a release, or included
> as apps, to a project and run without a problem. This can be complicated by
> having the build system do so much with the configuration files. Which is
> why I simply put them in priv and reference them that way. But something can
> be figured out.
>
> Tristan
>
> On Wed, Nov 3, 2010 at 7:40 PM, Noah Slater <ns...@apache.org> wrote:
>
>>
>> On 4 Nov 2010, at 00:33, Tristan Sloughter wrote:
>>
>> > What complex stuff is the build system dealing with?
>>
>> Everything outside of "erlc" :)
>>
>> - VPATH builds
>> - Configuring the install to find the location of C libraries
>> - Customising the install for users
>> - Setting up the system infrastructure for CouchDB to function
>> - Making sure things work across platforms
>> - Building customised versions of binaries and scripts
>>
>> > I'm separating the
>> > config file (and similar files) problem and the icu and couch_js problem.
>> I
>> > was hoping building those few C files wouldn't be bad, but I guess that
>> is
>> > not true from what you are saying?
>>
>> Doing the build system for an operating system daemon is Hard.
>>
>> > I'd still say it should be autotools, or whatever, inside an Erlang build
>> > system.
>>
>> Basically, I would like to see the new build system separate the package
>> into two components. The CouchDB OTP application, which is build using some
>> Erlang appropriate build system (like rebar, or whatever) and everything
>> else. Everything else is handled by Autotools, like it is now. Autotools is
>> also responsible for delegating the Erlang work off to the other build
>> system.
>>
>> A good way forward would be:
>>
>> - Decide the minimum set of files needed for the Erlang build.
>>
>> - Sandbox them into a directory along with the build files.
>>
>> - Create a Makefile.am file in that directory.
>>
>> - Hook the new system into the Autotools system.
>>
>> That should work.
>>
>> We get to keep teh AWSUM POWAH of Autotools, and have an OTP app. :)
>>
>> Valediction,
>>
>> N
>>
>>
>
Tristan,
Apologies for not replying earlier. I meant to but got distracted by
something shiny.
As Noah points out there are quite a few issues that are going to be
pain points with transitioning towards a non Autotools build. I'm
confident that we can and will but there are a few things to consider
as we do this. The following is going to be a brain dump to try and
outline the issues as best as I can. These are in no specific order
but hopefully give a good outline of what we're facing.
I will also preference this with the fact that our current source tree
is in desperate need of a makeover. We've been talking about it for
awhile and its at the point that it just needs to happen. The rest
that follows is my gathering of thoughts for the move.
1. We have constraints. Noah's pointed out a few, but I don't even
think that list is exhaustive. A project like CouchDB needs to pay
attention to a lot of different details. I've said before that Noah is
the Chuck Norris of Autotools, so any proposed changes will need to be
cleared by him. He is the de facto BDFL for our build system and I
will vote with him lock step on any proposal.
2. There are lots of things in our current build system that may seem
innocuous at first, but turn out to be A Big Deal in some specific
circumstances that aren't always apparent at first glance.
3. A lot of changes I see in your CouchDB branch aren't going to fly.
Some reasons may seem trivial but this is me relying on knowledge from
Noah Chuck Norris Slater.
4. I'm not sure about Sinan, but rebar won't work out of the box for a
default build tool because of a lack of support for VPATH builds. At
this moment I'm still concentrating on making sure we can do a full
rebar build to support things like Erlang releases, but it's been
de-prioritized to a "secondary build system" status. If Sinan can do
VPATH builds, then I think it'd be a very good thing to support.
5. Erlang build knowledge is at some level, incompatible with
Autotools build knowledge. We need to find a common ground and figure
out where we can compromise to hopefully make both work. My current
shimmering of an idea for rebar was to have a make target that was
something like "make rebar" which would short circuit some parts of a
default build with rebar. Its possible that we can revamp part of the
build system to overcome the constraints of Autotools, but as I see it
the first move might just make a "developer friendly" alternate build
style.
6. Your CouchDB branch has some major source movement. Unfortunately
the ASF has not yet moved to having native git support. As such, any
such patches of this magnitude must be developed with Subversion in
mind. The reason is that we cannot develop this patch set in git and
apply it directly to svn because it would castrate our history
(because svn is file oriented). To address this I've started a small
one-off project where we can concentrate our changes so they are
reproducible. The code is up at [1], but its not been hashed out as
much as it needs to be. Last I hacked on it, I was getting ready to
add the ability to apply a series of patches after the required
barrage of svn commands.
7. Removing dependencies from the source tree is not going to happen
any time soon. I wish we didn't have to vendor so many projects, but
we have to remember that a majority of people building CouchDB are not
Erlangians. Forcing our community to install a number of Erlang
dependencies to build CouchDB would be a very large hurdle to
navigate. I know that there are projects like faxien and rebar's git
support to overcome this, but I don't feel that there is a solution
that sufficiently addresses this issue.
8. I don't know about Sinan or Rebar's platform support specifically.
Building C code portably is very very hard. I know that people detest
Autotools for such things, but its got an uncountable number of man
years addressing platform specific build issues. I don't think its
impossible to replace for building C code, I just see it as staring at
a mountain when people suggest it. IIRC, one of my first conversations
with Noah was switching to SCons. As much as it pains me now to admit,
I'm glad at he laughed at me then.
9. I'm quite happy to see someone familiar with Sinan and Erlang build
tools to jump into this conversation. The Erlangian part of the
CouchDB community has known that these sorts of changes are necessary,
but for the most part our frame of reference has been rebar. Seeing
another build system's requirement will help a *lot* in moving this
discussion forward.
10. Minor point, but our rough plan is to apply this level of massive
change just after we release 1.1.x so that the upheaval has time to be
used by the early adopters.
I suddenly can't think of anything else. I'm sure I'm forgetting
points that are important, but hopefully that starts to illustrate the
scope of what confronts this move. I think that its going to be a
difficult project and I'm extremely happy to see another Erlanger
involved in the discussion. My biggest fear with this move is that we
only manage to move to the Uncanny Valley of Erlang source trees. We
have rebar as a planned target. Sinan would be a great use case to
have so we can be more sure that our changes are enabling more Erlang
happiness.
Hopefully that wasn't too much of a brain dump to scare anyone. This
move definitely needs to happen and right now its mostly about making
sure we have our bases covered.
Paul Davis
[1] http://github.com/davisp/couchdb-srcmv
Re: CouchDB OTP
Posted by Tristan Sloughter <tr...@gmail.com>.
Agreed. That sounds like a good plan. I'd just want to ensure that the
Erlang side can be installed as a release and run as a release, or included
as apps, to a project and run without a problem. This can be complicated by
having the build system do so much with the configuration files. Which is
why I simply put them in priv and reference them that way. But something can
be figured out.
Tristan
On Wed, Nov 3, 2010 at 7:40 PM, Noah Slater <ns...@apache.org> wrote:
>
> On 4 Nov 2010, at 00:33, Tristan Sloughter wrote:
>
> > What complex stuff is the build system dealing with?
>
> Everything outside of "erlc" :)
>
> - VPATH builds
> - Configuring the install to find the location of C libraries
> - Customising the install for users
> - Setting up the system infrastructure for CouchDB to function
> - Making sure things work across platforms
> - Building customised versions of binaries and scripts
>
> > I'm separating the
> > config file (and similar files) problem and the icu and couch_js problem.
> I
> > was hoping building those few C files wouldn't be bad, but I guess that
> is
> > not true from what you are saying?
>
> Doing the build system for an operating system daemon is Hard.
>
> > I'd still say it should be autotools, or whatever, inside an Erlang build
> > system.
>
> Basically, I would like to see the new build system separate the package
> into two components. The CouchDB OTP application, which is build using some
> Erlang appropriate build system (like rebar, or whatever) and everything
> else. Everything else is handled by Autotools, like it is now. Autotools is
> also responsible for delegating the Erlang work off to the other build
> system.
>
> A good way forward would be:
>
> - Decide the minimum set of files needed for the Erlang build.
>
> - Sandbox them into a directory along with the build files.
>
> - Create a Makefile.am file in that directory.
>
> - Hook the new system into the Autotools system.
>
> That should work.
>
> We get to keep teh AWSUM POWAH of Autotools, and have an OTP app. :)
>
> Valediction,
>
> N
>
>
Re: CouchDB OTP
Posted by Noah Slater <ns...@apache.org>.
On 4 Nov 2010, at 00:33, Tristan Sloughter wrote:
> What complex stuff is the build system dealing with?
Everything outside of "erlc" :)
- VPATH builds
- Configuring the install to find the location of C libraries
- Customising the install for users
- Setting up the system infrastructure for CouchDB to function
- Making sure things work across platforms
- Building customised versions of binaries and scripts
> I'm separating the
> config file (and similar files) problem and the icu and couch_js problem. I
> was hoping building those few C files wouldn't be bad, but I guess that is
> not true from what you are saying?
Doing the build system for an operating system daemon is Hard.
> I'd still say it should be autotools, or whatever, inside an Erlang build
> system.
Basically, I would like to see the new build system separate the package into two components. The CouchDB OTP application, which is build using some Erlang appropriate build system (like rebar, or whatever) and everything else. Everything else is handled by Autotools, like it is now. Autotools is also responsible for delegating the Erlang work off to the other build system.
A good way forward would be:
- Decide the minimum set of files needed for the Erlang build.
- Sandbox them into a directory along with the build files.
- Create a Makefile.am file in that directory.
- Hook the new system into the Autotools system.
That should work.
We get to keep teh AWSUM POWAH of Autotools, and have an OTP app. :)
Valediction,
N
Re: CouchDB OTP
Posted by Tristan Sloughter <tr...@gmail.com>.
Hmm, ok. I have replaced the build system. I am using sinan but it should be
buildable now with any Erlang/OTP build tool, like rebar. I am just running
it as a release from a script that erl-execs the boot file.
What complex stuff is the build system dealing with? I'm separating the
config file (and similar files) problem and the icu and couch_js problem. I
was hoping building those few C files wouldn't be bad, but I guess that is
not true from what you are saying?
I'd still say it should be autotools, or whatever, inside an Erlang build
system.
Tristan
On Wed, Nov 3, 2010 at 7:28 PM, Noah Slater <ns...@apache.org> wrote:
> Have you wholesale replaced the existing build system?
>
> If you have, it's going to be a tad more complex than knocking up a few
> makefiles to compile C. There's lots of very complex stuff our build system
> copes with at the moment. I'm not convinced it can be replaced by an Erlang
> build system and a few shell scripts. We've had chats about improving the
> build system before, and I think the consensus is that we wrap an Erlang
> build system WITHIN the Autotools system.
>
> What are you thoughts?
>
> On 4 Nov 2010, at 00:04, Tristan Sloughter wrote:
>
> > If anyone by chance has or can easily create some simplistic make files
> or
> > something for compiling the C code that would be AWESOME. I haven't had
> time
> > to dig around what is needed to compile the different pieces but its the
> > last major piece to complete.
> >
> > Tristan
> >
> > On Wed, Nov 3, 2010 at 10:52 AM, Tristan Sloughter <
> > tristan.sloughter@gmail.com> wrote:
> >
> >> Hi everyone, I have a github fork from apache/couchdb
> >> https://github.com/tsloughter/couchdb that I modified to be more OTP
> >> compliant and now builds with sinan (from http://erlware.org). There
> >> wasn't much that I've done so far. I moved the CouchDB app under
> >> lib/couchdb. I removed the other apps from the source tree, they can
> easily
> >> be installed with faxien (from http://erlware.org) and versions can be
> >> declared if necessary. I changed the _app.erl file to not start
> applications
> >> and added those applications instead to the applications list in the
> .app
> >> file. They will be started properly by the release's boot script.
> >>
> >> I moved all non-Erlang stuff to lib/couchdb/priv.
> >>
> >> I still have a number of things to do that I hope to get to tonight.
> First,
> >> fix up the two scripts under bin/. Fix the configuration file locations
> >> (some stuff is hardcoded for my environment). Add a hook to sinan to
> compile
> >> the icu driver -- right now I just copied the library over from a build
> of
> >> CouchDB I did separately.
> >>
> >> There are probably a few other things.. But I was able to do an
> >> application:start(couchdb) last night and see it working :).
> >>
> >> There were a few things I thought of changing within the code as I dug
> >> around but those are a separate issue that I'll bring up in discussion
> after
> >> all this is complete.
> >>
> >> Tristan
> >>
>
>
Re: CouchDB OTP
Posted by Noah Slater <ns...@apache.org>.
Have you wholesale replaced the existing build system?
If you have, it's going to be a tad more complex than knocking up a few makefiles to compile C. There's lots of very complex stuff our build system copes with at the moment. I'm not convinced it can be replaced by an Erlang build system and a few shell scripts. We've had chats about improving the build system before, and I think the consensus is that we wrap an Erlang build system WITHIN the Autotools system.
What are you thoughts?
On 4 Nov 2010, at 00:04, Tristan Sloughter wrote:
> If anyone by chance has or can easily create some simplistic make files or
> something for compiling the C code that would be AWESOME. I haven't had time
> to dig around what is needed to compile the different pieces but its the
> last major piece to complete.
>
> Tristan
>
> On Wed, Nov 3, 2010 at 10:52 AM, Tristan Sloughter <
> tristan.sloughter@gmail.com> wrote:
>
>> Hi everyone, I have a github fork from apache/couchdb
>> https://github.com/tsloughter/couchdb that I modified to be more OTP
>> compliant and now builds with sinan (from http://erlware.org). There
>> wasn't much that I've done so far. I moved the CouchDB app under
>> lib/couchdb. I removed the other apps from the source tree, they can easily
>> be installed with faxien (from http://erlware.org) and versions can be
>> declared if necessary. I changed the _app.erl file to not start applications
>> and added those applications instead to the applications list in the .app
>> file. They will be started properly by the release's boot script.
>>
>> I moved all non-Erlang stuff to lib/couchdb/priv.
>>
>> I still have a number of things to do that I hope to get to tonight. First,
>> fix up the two scripts under bin/. Fix the configuration file locations
>> (some stuff is hardcoded for my environment). Add a hook to sinan to compile
>> the icu driver -- right now I just copied the library over from a build of
>> CouchDB I did separately.
>>
>> There are probably a few other things.. But I was able to do an
>> application:start(couchdb) last night and see it working :).
>>
>> There were a few things I thought of changing within the code as I dug
>> around but those are a separate issue that I'll bring up in discussion after
>> all this is complete.
>>
>> Tristan
>>
Re: CouchDB OTP
Posted by Tristan Sloughter <tr...@gmail.com>.
If anyone by chance has or can easily create some simplistic make files or
something for compiling the C code that would be AWESOME. I haven't had time
to dig around what is needed to compile the different pieces but its the
last major piece to complete.
Tristan
On Wed, Nov 3, 2010 at 10:52 AM, Tristan Sloughter <
tristan.sloughter@gmail.com> wrote:
> Hi everyone, I have a github fork from apache/couchdb
> https://github.com/tsloughter/couchdb that I modified to be more OTP
> compliant and now builds with sinan (from http://erlware.org). There
> wasn't much that I've done so far. I moved the CouchDB app under
> lib/couchdb. I removed the other apps from the source tree, they can easily
> be installed with faxien (from http://erlware.org) and versions can be
> declared if necessary. I changed the _app.erl file to not start applications
> and added those applications instead to the applications list in the .app
> file. They will be started properly by the release's boot script.
>
> I moved all non-Erlang stuff to lib/couchdb/priv.
>
> I still have a number of things to do that I hope to get to tonight. First,
> fix up the two scripts under bin/. Fix the configuration file locations
> (some stuff is hardcoded for my environment). Add a hook to sinan to compile
> the icu driver -- right now I just copied the library over from a build of
> CouchDB I did separately.
>
> There are probably a few other things.. But I was able to do an
> application:start(couchdb) last night and see it working :).
>
> There were a few things I thought of changing within the code as I dug
> around but those are a separate issue that I'll bring up in discussion after
> all this is complete.
>
> Tristan
>