Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CAKmKYaB179aGmk13oCPGM4znOG9=p7K8AqCuD+2-vdsP3Ck4wg@mail.gmail.com>
References: 
 <CAKmKYaB179aGmk13oCPGM4znOG9=p7K8AqCuD+2-vdsP3Ck4wg@mail.gmail.com>
Date: Mon, 20 May 2013 16:39:12 +0100
Message-ID: 
 <CAPaJBx4NGpubbCGBEFH4GwXM53FF7tY0jDRovAUvXgW_zggWcA@mail.gmail.com>
Subject: Re: Getting rid of file lists in documentation Makefiles
From: Noah Slater <nslater@apache.org>
To: Dirkjan Ochtman <dirkjan@ochtman.nl>
Cc: "dev@couchdb.apache.org" <dev@couchdb.apache.org>,
 Noah Slater <nslater@apache.org>
Content-Type: multipart/alternative; boundary=089e01493cba69317604dd28228d

--089e01493cba69317604dd28228d
Content-Type: text/plain; charset=ISO-8859-1

I'm torn on this issue.

See:

http://www.gnu.org/software/automake/manual/automake.html#Wildcards

(Please read that whole section.)

Summary is:

 * Wildcards make it easy to distribute the wrong files (either too many,
or too few)

 * Wildcards are not portable

Please also consider that with Benoit's rcouch merge, we're moving away
from Autotools entirely (I believe), so we will have the chance to throw
off / simplify a lot of this stuff.

What are your thoughts having read that section?


On 20 May 2013 13:58, Dirkjan Ochtman <dirkjan@ochtman.nl> wrote:

> Hi there,
>
> Keeping Makefile.am in sync with the actual documentation is a PITA,
> and doesn't add any value. In fact, I broke the build over the weekend
> by not removing some files from the Makefiles. Instead, we can use
> invocations of find to find the relevant files in these cases:
>
> html_files := $(shell find ./html/ -type f -not -wholename "*doctree*"
> -not -name ".buildinfo")
> image_files := $(shell find ../images/ -type f)
> src_files := $(shell find ../src/ -name "*.rst" -or -name "conf.py")
> src_files_html := $(shell find ../static/ ../templates/ -type f)
>
> (This would replace the respective lists of files in
> share/doc/build/Makefile.am.)
>
> Anyone opposed to that?
>
> Cheers,
>
> Dirkjan
>


-- 
NS

--089e01493cba69317604dd28228d--