On Fri, Jun 04, 2004 at 11:49:31AM -0700, Stas Bekman wrote:
> Why is that everybody suddenly has the time to go on huge threads pushing
> for 1.0 release and totally ignoring efforts to make a solid 1.0 first. How
> many times do I have to ask whether my suggestion for making the API more
> sensible before I'll get some feedback? Several people +1'd that this needs
> to be done *before* 1.0 is released. and since then I'm talking to a wall :(
I think you wanted an expert opinion, but here's my take anyway ...
> Thanks. So what's the next step? How one performs this kind of rename? I
> have
> seen that done with functions, not sure how does it work for enums. I guess
> defines are the same as functions.
>
> Should it be s/APR_/APR_FILETYPE_/ and s/APR_/APR_FINFO_/ or something else?
> Like so?
>
> typedef enum {
> APR_FILETYPE_NOFILE = 0, /**< no file type determined */
> APR_FILETYPE_REG, /**< a regular file */
> APR_FILETYPE_DIR, /**< a directory */
> APR_FILETYPE_CHR, /**< a character device */
> APR_FILETYPE_BLK, /**< a block device */
> APR_FILETYPE_PIPE, /**< a FIFO / pipe */
> APR_FILETYPE_LNK, /**< a symbolic link */
> APR_FILETYPE_SOCK, /**< a [unix domain] socket */
> APR_FILETYPE_UNKFILE = 127 /**< a file of some other unknown type */
> } apr_filetype_e;
Looks right to me. Something like this would do it:
for f in `find . -regex '.*\.\([ch]\(\.in\)?\|hnw\|hw\)$'`; do
sed
-e
's/APR_\(REG\|DIR\|CHR\|BLK\|PIPE\|LNK\|SOCK\|UNKFILE\)/APR_FILETYPE_\1/'
-e 's/APR_\(U\|G\|W\)\(READ\|WRITE\|EXECUTE\)/APR_FINFO_\1\2/'
$f >${f}.rename
mv -f ${f}.rename $f
done
Do that on a clean checkout, compile, and check the diff for sanity. I don't
think there's much else to it.
