Re: [ccache] Release plan

2010-02-28 Thread William S Fulton

Joel Rosdahl wrote:

Hi,

I now don't have any features left on my TODO list for the next ccache 
release,
which I plan to name 3.0. The main thing left, except more testing and 
fixing

any bugs that are found, is some work on the documentation, and maybe some
portability stuff.

There are still some features that I would like to work on, though, 
but that I

think should wait until after 3.0:

  - Support for a configuration file in the cache directory. I will 
send a mail

to the list with some thoughts on this later.

  - Support for choosing hash algorithm (at least MD4, MD5 and SHA-1).

  - Support for optionally hashing the output of "$CC $flag" (e.g., 
"gcc -v" or

"gcc -dumpspecs") to identify the compiler instead of relying on
mtime/size.

Does this seem reasonable? And does anyone have other feature requests or
semi-forks with features that could be incorporated in later ccache 
versions?

Comments are welcome.
Joel, a new release is long overdue, so I'm really pleased to see this 
happening - thanks. How about the new release is updated with the latest 
GPL - version 3? Given you are changing the ccache version number quite 
considerably, this would also be a good opportunity to update the 
license version to make it distinguishable from prior releases.


I have a "semi-fork" of ccache for SWIG. See 
http://swig.svn.sourceforge.net/viewvc/swig/trunk/CCache/. It adds 
support for the SWIG compiler in addition to C/C++ compilers. The main 
difference to a traditional compiler is that SWIG can generate more than 
one file and ccache works equally well for it. I don't know if the 
changes are suitable for incorporation into the main ccache at some 
point - comments welcome. However, it would be good to port the 
CCACHE_VERBOSE option from this fork to ccache - it displays all the 
compiler invocations it makes and it is really useful for debugging 
ccache problems as both an end user and a developer.


William
___
ccache mailing list
ccache@lists.samba.org
https://lists.samba.org/mailman/listinfo/ccache


[ccache] ccache 3.0pre0 has been released

2010-02-28 Thread Joel Rosdahl
Hi,

I'm pleased to announce ccache version 3.0pre0. I expect this prerelease (or
call it beta release if you want) to not differ much from the upcoming 3.0
release functionality-wise, so I encourage everyone to try it out. And please
report any bugs or misbehaviours you find to this mailing list or the bug
tracker.

The source archive can be found here:

http://samba.org/ftp/ccache/ccache-3.0pre0.tar.bz2
http://samba.org/ftp/ccache/ccache-3.0pre0.tar.gz

To find out what has changed since the previous version (2.4), please see the
NEWS file:

http://samba.org/ftp/ccache/ccache-3.0pre0-NEWS

-- Joel
___
ccache mailing list
ccache@lists.samba.org
https://lists.samba.org/mailman/listinfo/ccache


Re: [ccache] Release plan

2010-02-28 Thread Ramiro Polla
On Sun, Feb 28, 2010 at 5:11 PM, Joel Rosdahl  wrote:
> And does anyone have other feature requests or
> semi-forks with features that could be incorporated in later ccache versions?

I have a win32 port almost done. But since it touches *a lot* of code
I'd rather wait for after 3.0 so it can receive more testing.

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


[ccache] Release plan

2010-02-28 Thread Joel Rosdahl
Hi,

I now don't have any features left on my TODO list for the next ccache release,
which I plan to name 3.0. The main thing left, except more testing and fixing
any bugs that are found, is some work on the documentation, and maybe some
portability stuff.

There are still some features that I would like to work on, though, but that I
think should wait until after 3.0:

  - Support for a configuration file in the cache directory. I will send a mail
to the list with some thoughts on this later.

  - Support for choosing hash algorithm (at least MD4, MD5 and SHA-1).

  - Support for optionally hashing the output of "$CC $flag" (e.g., "gcc -v" or
"gcc -dumpspecs") to identify the compiler instead of relying on
mtime/size.

Does this seem reasonable? And does anyone have other feature requests or
semi-forks with features that could be incorporated in later ccache versions?
Comments are welcome.

-- Joel
___
ccache mailing list
ccache@lists.samba.org
https://lists.samba.org/mailman/listinfo/ccache


Re: [ccache] [PATCH] Always close(fd) as soon as file is mmap()'d.

2010-02-28 Thread Joel Rosdahl
On Sun, 28 Feb 2010 12:22:56 -0300
Ramiro Polla  wrote:

> On Sun, Feb 28, 2010 at 5:52 AM, Joel Rosdahl  wrote:
> > On Sat, 27 Feb 2010 22:15:54 -0300
> > Ramiro Polla  wrote:
> >> On remember_include_file(), close() wasn't even being called. On
> >> unify_hash() and process_preprocessed_file(), it might not be closed
> >> if mmap fails.
> >
> > Thanks for finding this! But I think you forgot to attach your patch?
> 
> Hmm, gmail says it's attached. Let's try again.

Thanks, got it.

Apparently, the mailing list settings were quite paranoid regarding
attachments and stripped your patch. I've now loosened the attachment
type filter somewhat.

-- Joel
___
ccache mailing list
ccache@lists.samba.org
https://lists.samba.org/mailman/listinfo/ccache


Re: [ccache] [PATCH] Always close(fd) as soon as file is mmap()'d.

2010-02-28 Thread Joel Rosdahl
On Sat, 27 Feb 2010 22:15:54 -0300
Ramiro Polla  wrote:

> On remember_include_file(), close() wasn't even being called. On
> unify_hash() and process_preprocessed_file(), it might not be closed
> if mmap fails.

Thanks for finding this! But I think you forgot to attach your patch?

-- Joel
___
ccache mailing list
ccache@lists.samba.org
https://lists.samba.org/mailman/listinfo/ccache