My concern is that when you use wildcards, a malicious (or broken) program could add files to the output that are then bundled up, and we end up shipping them in a release. At the moment, every file that we ship has been explcitly included. Having said that, my release procedure is now sufficiently advanced that I can detect missing/extra files, as well as "surprising" content. So I am not sure I need to be as vigilant about this as I used to be...
With that in mind, I'd say: do whatever you think is best. On 20 May 2013 21:55, Dirkjan Ochtman <[email protected]> wrote: > On Mon, May 20, 2013 at 5:39 PM, Noah Slater <[email protected]> wrote: > > 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 > > Yes, I understand the concerns. On the other hand, I don't think most > of those concerns apply cleanly to for example a Sphinx project. In > particular, Sphinx already complains if src files are either missing > or unused, so you'll get warnings about that. And Sphinx populates the > build directory from scratch every time, so problems with the HTML > output also seem fairly unlikely. On the other hand, forgetting to > update the file lists in the Makefile.am will have no effect on > building the docs, but will fail make distcheck. To me, at least, in > this context, DRY a bigger concern to me. > > To be fair, portability is a concern. Dave, does the typical Windows > build environment already have a find tool available to it? (Either > just some compiled GNU tools or a full Cygwin environment?) > > > 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. > > Ah, yes. Do we have a time frame for that? > > > What are your thoughts having read that section? > > Still the same, in this particular context, for the reasons explained > above. > > Cheers, > > Dirkjan > -- NS
