couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
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 <nslater@apache.org> wrote:

> On 4 October 2013 16:09, Jan Lehnardt <jan@apache.org> 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 Makefile.am
>> 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/Makefile.am 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/Makefile.am, and remove the
> Makefile.am 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 configure.ac, when they want their Makefile.am
> 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:
>> https://git-wip-us.apache.org/repos/asf/couchdb/repo?p=couchdb.git;a=log;h=refs/heads/build-system-fixes-1.5.x
>>  GitHub Compare:
>> https://github.com/janl/couchdb/compare/build-system-fixes-1.5.x
>> 
>> I’d appreciate a review :)
> 
> 
> Okay, using this:
> 
> https://github.com/janl/couchdb/compare/apache:1.5.x...build-system-fixes-1.5.x
> 
>> configure.ac
> 
> Remove this line:
> 
>    +AC_CONFIG_FILES([src/my-first-couchdb-plugin/Makefile])
> 
> (As part of the move of EXTRA_DIST to src/Makefile.am.)

of course, a leftover from my trials above.


>> license.skip
> 
> These lines are redundant:
> 
>    +^src/couchjs-node/Makefile
>    +^src/couchjs-node/Makefile.in
> 
> These files should be covered the the lines above this:
> 
>    ^Makefile
>    ^Makefile.in
> 
> 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/Makefile.am
> 
> This looks okay:
> 
>    +EXTRA_DIST = $(source_files) README.md
> 
> 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.

Best
Jan
-- 


Mime
View raw message