s/vbuilds/vpath builds/ I obviously need another cup...
On Wed, Jan 27, 2010 at 10:34 AM, Paul Joseph Davis (JIRA) <[email protected]> wrote: > > [ > https://issues.apache.org/jira/browse/COUCHDB-583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805539#action_12805539 > ] > > Paul Joseph Davis commented on COUCHDB-583: > ------------------------------------------- > > @Filipe, > > Actually you want to use test_util:src_file(Path). > > The way to double check that you have everything down pat is to run: > > $ make distcheck > > And that'll go through the full set of checks to see if your code is > distribution ready. > > For a brief explanation, autotools has a feature called vbuilds that allows > people to expand the source on a read-only mount, and then build to a > writable location. So you have two directories (srcdir and builddir) and > srcdir must be treated as read-only. This means that if you want to touch a > file that was part of the release tarball (not all files in SVN are part of > this, touching files during a build that aren't part of a release also causes > errors) you use srcdir. If the file of interest is a file that's being > written to, or was generated as part of a make rule, then it's in builddir. > > The relevant autotools docs are: > > http://www.gnu.org/software/hello/manual/automake/VPATH-Builds.html > http://www.gnu.org/software/make/manual/html_node/General-Search.html > http://www.gnu.org/software/make/manual/html_node/Commands_002fSearch.html#Commands_002fSearch > > Those all go over the weirdness to some extent. I'm remembering another > helpful page vaguely but can't figure out what it was. > >> storing attachments in compressed form and serving them in compressed form >> if accepted by the client >> ---------------------------------------------------------------------------------------------------- >> >> Key: COUCHDB-583 >> URL: https://issues.apache.org/jira/browse/COUCHDB-583 >> Project: CouchDB >> Issue Type: New Feature >> Components: Database Core, HTTP Interface >> Environment: CouchDB trunk >> Reporter: Filipe Manana >> Attachments: couchdb-583-trunk-10th-try.patch, >> couchdb-583-trunk-11th-try.patch, couchdb-583-trunk-12th-try.patch, >> couchdb-583-trunk-13th-try.patch, couchdb-583-trunk-14th-try-git.patch, >> couchdb-583-trunk-15th-try-git.patch, couchdb-583-trunk-3rd-try.patch, >> couchdb-583-trunk-4th-try-trunk.patch, couchdb-583-trunk-5th-try.patch, >> couchdb-583-trunk-6th-try.patch, couchdb-583-trunk-7th-try.patch, >> couchdb-583-trunk-8th-try.patch, couchdb-583-trunk-9th-try.patch, >> jira-couchdb-583-1st-try-trunk.patch, jira-couchdb-583-2nd-try-trunk.patch >> >> >> This feature allows Couch to gzip compress attachments as they are being >> received and store them in compressed form. >> When a client asks for downloading an attachment (e.g. GET >> somedb/somedoc/attachment.txt), the attachment is sent in compressed form if >> the client's http request has gzip specified as a valid transfer encoding >> for the response (using the http header "Accept-Encoding"). Otherwise couch >> decompresses the attachment before sending it back to the client. >> Attachments are compressed only if their MIME type matches one of those >> listed in a separate config file. Compression level is also configurable in >> the default.ini file. >> This follows Damien's suggestion from 30 November: >> "Perhaps we need a separate user editable ini file to specify compressable >> or non-compressable files (would probably be too big for the regular ini >> file). What do other web servers do? >> Also, a potential optimization is to compress the file while writing to >> disk, and serve the compressed bytes directly to clients that can handle it, >> and decompressed for those that can't. For compressable types, it's a win >> for both disk IO for reads and writes, and CPU on read." >> Patch attached. > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > >
