couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject Re: [1.5.0] Punted for today :(
Date Mon, 07 Oct 2013 15:00:03 GMT
Thanks Noah, this is really useful.

Notes inline.

On Oct 5, 2013, at 15:40 , Noah Slater <> wrote:

> On 4 October 2013 16:09, Jan Lehnardt <> wrote:
>> Adding it to EXTRA_DIST seemed to do the trick
> Aha! That was the correct thing to do.
>> This only applies to master and not 1.5.x, but there is a new
>> src/my-first-couchdb-plugin directory that just has bunch of files
>> that we just want to have in the tarball, but do nothing with yet.
>> For now I just made it like couchjs-node with the custom
>> and EXTRA_DIST and that seems to work, but the subdir has its own
>> Makefile that is irrelevant to the CouchDB build system (it is a
>> skeleton for building CouchDB plugins in a more standalone way).
>> Keeping that file named `Makefile` obviously conflicted with the
>> procedure, so I renamed it to `Makefile.dist` and added a step
>> to the instructions that asks the user to rename it before starting
>> development on a plugin. To circumvent the renaming step I tried
>> adding an EXTRA_DIST to src/ and reference all files
>> in src/my-first-couchdb-plugin from there, but that didn’t seem to
>> work. This one isn’t too important for now, but if there is a nice
>> solution, I’d like to know some time :)
> Oh, interesting.
> In this case, I would put the EXTRA_DIST in src/, and remove the
> from src/my-first-couchdb-plugin. The EXTRA_DIST will obviously
> have to prefix all the filenames with my-first-couchdb-plugin, but that's
> fine. And you can call your Makefile whatever you want.
> The instructions will need to be updated so that people are instructed to
> sprinkle the magic dust on, when they want their
> to be picked up by the build system

I tried that, but it failed with “no target for…” and then the first item
in EXTRA_DIST but I might have done something wrong, I’ll try this again
later. Thanks for confirming that it should work :)

> I’ve prepared a branch build-system-fixes-1.5.x that includes all
>> of the above.
>>  ASF:
>>  GitHub Compare:
>> I’d appreciate a review :)
> Okay, using this:
> Remove this line:
>    +AC_CONFIG_FILES([src/my-first-couchdb-plugin/Makefile])
> (As part of the move of EXTRA_DIST to src/

of course, a leftover from my trials above.

>> license.skip
> These lines are redundant:
>    +^src/couchjs-node/Makefile
>    +^src/couchjs-node/
> These files should be covered the the lines above this:
>    ^Makefile
>    ^
> I am uncomfortable with this:

Hm, weird, they showed up anyway, will test.

> +^src/my-first-couchdb-plugin/.*
> We should probably be explicit about what files do not need our
> boilerplate. If we're shipping example code, then it is under an Apache
> license, and should have the boilerplate. (Perhaps I am missing something
> there though?)

The idea is that my-first-couchdb-plugin is really its own self contained
thing. The expectation is that people copy this and write their own plugins.
I wanted to avoid setting people one way or another when choosing a license,
because they are free to create non-Apache-2 licensed plugins, but I am
equally happy to just set a precedent.

>> src/couch_plugins/
> This looks okay:
>    +EXTRA_DIST = $(source_files)
> But we shouldn't be distributing other people's README files, unless there
> is a very good reason. Should we rip this out?

This is our own README :) — It is a couch_plugins internal document that
when done can be thrown away with parts extracted into the main docs, but
for now a close-to-the-source README is the right thing here.

>> src/my-first-couchdb-plugin/.gitignore
> Why have a separate .gitignore here. Can we not include this rule in the
> top-level file?

Same as above, this is a self-contained thing and I expect people to copy
and customise, I just want them to not have to worry about setting up their
own ignore file.

Since the user copies are likely outside of the CouchDB source tree, I
thought having a custom one would make most sense.


View raw message