Hi,

I updated the fork at http://github.com/ramiropolla/ccache

I also went through all the issues from other forks from
http://code.google.com/p/ccache-win32/ and
http://gitorious.org/ccache-win and fixed them.

I'm CCing everyone that seemed involved in the development of those
other projects so they are aware that work is being done upstream.

On Tue, Jul 13, 2010 at 1:36 PM, Joel Rosdahl <j...@rosdahl.net> wrote:
> On 2010-07-12 23:05, Ramiro Polla wrote:
>>> Why is the special handling of shell scripts needed?
>>
>> It had something to do with the regression tests. When the compiler
>> being called is a script around the actual compiler, CreateProcess
>> fails.
>
> OK.

I added shebang detection under an environment variable. ".sh"
detection is still default though.

>> Do you think you could update the list configuration so that Reply-To
>> points to the list instead of the sender?
>
> I personally don't like mailing lists that set the Reply-To header to
> the list (for reasons listed on
> <http://www.unicom.com/pw/reply-to-harmful.html>) so my vote is to keep
> the current settings, but if a larger part of the list members want it,
> I'm open for a change.

Hm, if you think it's not good then I don't mind... It's just that for
me "least surprise" would be receiving an email from a list and
replying to the list =).

> Why is a check for both "ccache" and "ccache.exe" needed? Doesn't
> argv[0] on Windows always end with the actual extension? The reason I'm
> asking is that if only "ccache.exe" is needed, we could maybe use the
> EXEEXT variable from autoconf and avoid the conditional compilation.

I added the check under helper functions in utils.c.

> We should probably use PATH_DELIM for CCACHE_EXTRAFILES as well.

Probably, but I haven't looked into that yet.

> "Introduce and use x_fmmap()": Nice cleanup in general. A comment with
> some documention of x_fmmap's semantics and parameters would be nice.
> And maybe remove trailing space from last argument when calling x_fmmap
> and add a space in the format strings in x_fmmap instead?
>
> "Don't dup fd for zlib, and gzclose() gzdopen()d file": The gzclose() is
> fine, but I'm not sure about the removal of dup() since that will make
> copy_fd close fd_in because gzclose() will close it.
[...]
> "Close manifest files before moving them": You can remove "if (f1) {
> gzclose(f1) }" in "out:". Also, close(fd) shouldn't be needed after
> gzclose(f) when f was created with gzdopen(fd, ...).

All dealt with.

> General: Please don't put a period in the commit summary (i.e., first
> line of the commit message).

Done.

> I suspect that the static inline functions in ccache.h will result in
> portibility problems, so I think it's better to just move them to util.c.

Done along with many other helper functions.

Ramiro Polla
_______________________________________________
ccache mailing list
ccache@lists.samba.org
https://lists.samba.org/mailman/listinfo/ccache

Reply via email to