Re: Standardize NO_CCACHE flag and ccache definitions
On Sat, 21 Jun 2008 17:06:41 +0200 Martin Tournoij <[EMAIL PROTECTED]> wrote: > As a sidenote, AFAIK cons and scons are not related... They are distantly related. The Software Carpentry project was looking for a make replacement. Cons was not eligible because it (and thus its configuration) was written in perl and all scripting within Software Carpentry had to be in Python. So Steve Knight rewrote Cons in python as PCons fixing some of the shortcomings of Cons at the same time. Essentially this was Cons2, since not much happened to the original Cons after this. PCons became ScCons and then Scons. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Standardize NO_CCACHE flag and ccache definitions
On Sat, 21 Jun 2008 10:25:41 -0500, Alex Kozlov <[EMAIL PROTECTED]> wrote:
On Sat, Jun 21, 2008 at 01:32:20AM +0100, RW wrote:
On Wed, 18 Jun 2008 23:27:16 +0200
Martin Tournoij <[EMAIL PROTECTED]> wrote:
> There are some ports which refuse to compile with ccache, these all
> seem to be projects which use scons, unlike make, scons does not copy
> the user's environment automatically, and the required environment
> variables for ccache (like CCACHE_DIR) aren't present, which leads to
> build failure, an example is games/freera.
>
> I'm not that familiar with scons, and what exactly the "proper way" is
> to handle this sort of stuff in scons,
I don't have any experience with scons, but I did used to use cons.
IIRC cons expects to do the caching itself. Since it already generates a
hash that can be used to label the correct object file, it pretty much
comes for free and running ccache would just duplicate the overheads. I
think it's probable that there isn't a "proper way".
From porter's handbook:
To make third party SConstruct respect everything that is passed to SCons
in SCONS_ENV (that is, most importantly, CC/CXX/CFLAGS/CXXFLAGS), patch
the SConstruct so build Environment is constructed like this:
env = Environment(**ARGUMENTS)
It may be then modified with env.Append and env.Replace.
I have solved with ccache issue in net-p2p/linuxdcpp by tweak os.environ
stuff in SConstruct and add SCONS_BUILDENV=${SCONS_ENV} in
linuxdcpp/Makefile.
Cheers,
Mezz
--
Adios
--
[EMAIL PROTECTED] - [EMAIL PROTECTED]
FreeBSD GNOME Team
http://www.FreeBSD.org/gnome/ - [EMAIL PROTECTED]
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Standardize NO_CCACHE flag and ccache definitions
On Sat, Jun 21, 2008 at 01:32:20AM +0100, RW wrote: > On Wed, 18 Jun 2008 23:27:16 +0200 > Martin Tournoij <[EMAIL PROTECTED]> wrote: > > > > There are some ports which refuse to compile with ccache, these all > > seem to be projects which use scons, unlike make, scons does not copy > > the user's environment automatically, and the required environment > > variables for ccache (like CCACHE_DIR) aren't present, which leads to > > build failure, an example is games/freera. > > > > I'm not that familiar with scons, and what exactly the "proper way" is > > to handle this sort of stuff in scons, > > I don't have any experience with scons, but I did used to use cons. > IIRC cons expects to do the caching itself. Since it already generates a > hash that can be used to label the correct object file, it pretty much > comes for free and running ccache would just duplicate the overheads. I > think it's probable that there isn't a "proper way". >From porter's handbook: To make third party SConstruct respect everything that is passed to SCons in SCONS_ENV (that is, most importantly, CC/CXX/CFLAGS/CXXFLAGS), patch the SConstruct so build Environment is constructed like this: env = Environment(**ARGUMENTS) It may be then modified with env.Append and env.Replace. -- Adios ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Standardize NO_CCACHE flag and ccache definitions
On Sat, Jun 21, 2008 at 01:32:20AM +0100, RW wrote: > On Wed, 18 Jun 2008 23:27:16 +0200 > Martin Tournoij <[EMAIL PROTECTED]> wrote: > > > There are some ports which refuse to compile with ccache, these all > > seem to be projects which use scons, unlike make, scons does not copy > > the user's environment automatically, and the required environment > > variables for ccache (like CCACHE_DIR) aren't present, which leads to > > build failure, an example is games/freera. > > > > I'm not that familiar with scons, and what exactly the "proper way" is > > to handle this sort of stuff in scons, > > I don't have any experience with scons, but I did used to use cons. > IIRC cons expects to do the caching itself. Since it already generates a > hash that can be used to label the correct object file, it pretty much > comes for free and running ccache would just duplicate the overheads. I > think it's probable that there isn't a "proper way". It's not quite the same, scons' cache feature needs to be explicitly enabled in the SConstruct file, I don't think many projects have it enabled... See the scons manual: http://www.scons.org/doc/0.98.5/HTML/scons-user/c3143.html A NO_CCACHE might be useful for ports that do have this cache enabled, but are there any ports at all which use this? As a sidenote, AFAIK cons and scons are not related... -- Martin Tournoij [EMAIL PROTECTED] http://www.daemonforums.org QOTD: The fact that Hitler was a political genius unmasks the nature of politics in general as no other can. -- Wilhelm Reich ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Standardize NO_CCACHE flag and ccache definitions
On Wed, 18 Jun 2008 23:27:16 +0200 Martin Tournoij <[EMAIL PROTECTED]> wrote: > There are some ports which refuse to compile with ccache, these all > seem to be projects which use scons, unlike make, scons does not copy > the user's environment automatically, and the required environment > variables for ccache (like CCACHE_DIR) aren't present, which leads to > build failure, an example is games/freera. > > I'm not that familiar with scons, and what exactly the "proper way" is > to handle this sort of stuff in scons, I don't have any experience with scons, but I did used to use cons. IIRC cons expects to do the caching itself. Since it already generates a hash that can be used to label the correct object file, it pretty much comes for free and running ccache would just duplicate the overheads. I think it's probable that there isn't a "proper way". ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Standardize NO_CCACHE flag and ccache definitions
On Wed, Jun 18, 2008 at 10:51:54PM +1000, Edwin Groothuis wrote: > Hello, > > Recently I've started to use devel/ccache again (sometimes it takes > a while before you understand how it works) and it works pretty > well, except for some ports which can't be build with it. For example > devel/cmake. > > To prevent everybody from having to re-invent the wheel, we could > introduce a NO_CCACHE flag in the affected ports Makefile: > > NO_CCACHE=yes Hi Edwin, There are some ports which refuse to compile with ccache, these all seem to be projects which use scons, unlike make, scons does not copy the user's environment automatically, and the required environment variables for ccache (like CCACHE_DIR) aren't present, which leads to build failure, an example is games/freera. I'm not that familiar with scons, and what exactly the "proper way" is to handle this sort of stuff in scons, I looked at it some time ago for a port I maintain (graphics/gsculpt), and from what I remember, just copying the entire user's environment to the scons build environment is not as easy as it sounds, I don't remember the details. The fix I used was to just copy the ccache environment variables ... Quick 'n dirty, but it works. I didn't look at it very long, so there could be a better way. Note that some applications like graphics/blender work fine with ccache without modification (Note that the current blender port doesn't use scons, but a previous version did). Writing *good* SConstruct files seems to be relatively hard/complicated ... Which is seems to be why most projects don't have good SConstruct files. In any case, there seem to be only a few isolated ports which don't compile with ccache, fixing those also seems to be pretty easy ... So before implementing NO_CCACHE fixing the ports seems like a better idea IMO, if you want I can search for broken scons ports and fix if necessary. Not sure if there are other scenarios where ccache fails, I have used it for years in various environments (including jails/tinderboxes) without any problems other than those outlined above. -- Martin Tournoij [EMAIL PROTECTED] http://www.daemonforums.org QOTD: We all like praise, but a hike in our pay is the best kind of ways. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Standardize NO_CCACHE flag and ccache definitions
On Wed, 18 Jun 2008 22:06:21 +0300 Alex Kozlov <[EMAIL PROTECTED]> wrote: > In typical case check for size and mtime is enough. It's not really a question of good enough, if you use the mtime of the driver on all builds, then *every* time you rebuild the compiler, you invaldate all the cache objects that have been built with it. That can have a major impact on port building, and it's in things like "portupgrade -rf gettext" where ccache is most significant. Using the hash avoids that problem. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Standardize NO_CCACHE flag and ccache definitions
On Wed, Jun 18, 2008 at 07:05:36PM +0100, RW wrote:
> On Wed, 18 Jun 2008 20:23:52 +0300
> Alex Kozlov <[EMAIL PROTECTED]> wrote:
> > This is not luck. To think more about this, CCACHE_HASH_COMPILER
> > and CCACHE_NOHASH_SIZE_MTIME is two method for the same.
> > hash size and mtime is lightweight and CCACHE_HASH_COMPILER
> > is more heavy.
> It's negligible, it added a few seconds to a build of Firefox,
> and I had to build it ten times to determine that because the
> build-to-build variations are much greater.
I check this.
> > But in case of buildworld CCACHE_HASH_COMPILER is still not necessary,
> > CCACHE_NOHASH_SIZE_MTIME is enough.
> It depends what you want to achieve, the object of ccache is to
> cache compiler outputs where the results are identical to a fresh
> build (subject to possible minor exceptions like source file paths). If
> you don't detect compiler updates then you can no longer say that's
> true.
In typical case check for size and mtime is enough.
For buildworld We can disable even it, because compiler version
very rare change in RELENG_X lifetime.
In case of tinderbox farm I'm not so sure, if jails don't share
.ccache it probably relatively safe. This is need checking.
If overhead for CCACHE_HASH_COMPILER not big, may be worth turn
it on. Also need testing.
For too smart for it own good ports We can add to /etc/make.conf
something like this:
.if ${.CURDIR:N*/ports/devel/cmake} !="" && ...
CC = ccache
CXX = ccache
.endif
> If you use CCACHE_NOHASH_SIZE_MTIME then you are accepting object files
> produced by mixture of, arbitrarily old, versions of the compiler. If a
> new compiler version brings in better code generation, I'd rather pick
> it up.
>
> CCACHE_HASH_COMPILER is a good compromise IMO, because it will detect
> changes in the driver, without being sensitive to minor world rebuilds.
> You still need to watch for security updates to GCC because in
> principle they might not affect the drivers, that's rare though.
--
Adios
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Standardize NO_CCACHE flag and ccache definitions
On Wed, 18 Jun 2008 20:23:52 +0300 Alex Kozlov <[EMAIL PROTECTED]> wrote: > This is not luck. To think more about this, CCACHE_HASH_COMPILER > and CCACHE_NOHASH_SIZE_MTIME is two method for the same. > hash size and mtime is lightweight and CCACHE_HASH_COMPILER > is more heavy. It's negligible, it added a few seconds to a build of Firefox, and I had to build it ten times to determine that because the build-to-build variations are much greater. > But in case of buildworld CCACHE_HASH_COMPILER is still not necessary, > CCACHE_NOHASH_SIZE_MTIME is enough. It depends what you want to achieve, the object of ccache is to cache compiler outputs where the results are identical to a fresh build (subject to possible minor exceptions like source file paths). If you don't detect compiler updates then you can no longer say that's true. If you use CCACHE_NOHASH_SIZE_MTIME then you are accepting object files produced by mixture of, arbitrarily old, versions of the compiler. If a new compiler version brings in better code generation, I'd rather pick it up. CCACHE_HASH_COMPILER is a good compromise IMO, because it will detect changes in the driver, without being sensitive to minor world rebuilds. You still need to watch for security updates to GCC because in principle they might not affect the drivers, that's rare though. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Standardize NO_CCACHE flag and ccache definitions
On Wed, Jun 18, 2008 at 06:44:36PM +0200, Alex Dupre wrote: >> Problem in make buildworld case is not compiler name. > hash_file() doesn't hash the file name :-) Yes, sorry. s/name/identity/. In other words this check to make sure that obj was created the same compiler. > You are lucky that CCACHE_HASH_COMPILER is checked before > CCACHE_NOHASH_SIZE_MTIME. This is not luck. To think more about this, CCACHE_HASH_COMPILER and hash size and mtime is two method for the same. Former is lightweight and CCACHE_HASH_COMPILER is more heavy. But in case of buildworld CCACHE_HASH_COMPILER is still not necessary, CCACHE_NOHASH_SIZE_MTIME is enough. -- Adios ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Standardize NO_CCACHE flag and ccache definitions
On Wed, Jun 18, 2008 at 06:44:36PM +0200, Alex Dupre wrote: > Alex Kozlov wrote: > > Problem in make buildworld case is not compiler name. > hash_file() doesn't hash the file name :-) Yes, sorry. s/name/identity/. In other world this check to make sure that obj was created the same compiler. > You are lucky that CCACHE_HASH_COMPILER is checked before > CCACHE_NOHASH_SIZE_MTIME. This is not luck. To think more about this, CCACHE_HASH_COMPILER and CCACHE_NOHASH_SIZE_MTIME is two method for the same. hash size and mtime is lightweight and CCACHE_HASH_COMPILER is more heavy. But in case of buildworld CCACHE_HASH_COMPILER is still not necessary, CCACHE_NOHASH_SIZE_MTIME is enough. -- Adios ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Standardize NO_CCACHE flag and ccache definitions
Alex Kozlov wrote: > Problem in make buildworld case is not compiler name. hash_file() doesn't hash the file name :-) You are lucky that CCACHE_HASH_COMPILER is checked before CCACHE_NOHASH_SIZE_MTIME. -- Ale ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Standardize NO_CCACHE flag and ccache definitions
On Wed, 18 Jun 2008 18:26:14 +0300
Alex Kozlov <[EMAIL PROTECTED]> wrote:
> On Wed, Jun 18, 2008 at 05:05:42PM +0200, Alex Dupre wrote:
> > Alex Kozlov ha scritto:
> > > Don't use it for building ports. Actualy it's not necessary even
> > > for make buildworld.
> >
> > It's necessary if you don't want to use ccache only for 1% of the
> > buildworld process.
> I use CCACHE_NOHASH_SIZE_MTIME:
>
> if (getenv("CCACHE_HASH_COMPILER")) {
> hash_file(args->argv[0]);
> } else if (!getenv("CCACHE_NOHASH_SIZE_MTIME")) {
> hash_int(st.st_size);
> hash_int(st.st_mtime);
> }
>
I'm not sure what your point is here.
CCACHE_HASH_COMPILER is by far the more conservative of the two. I use
CCACHE_HASH_COMPILER all the time, it hasn't caused any problems. The
cost of hashing the compiler driver is negilible.
If you don't set either then each time you rebuild world you
invalidate most of your cache.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Standardize NO_CCACHE flag and ccache definitions
On Wed, Jun 18, 2008 at 05:48:38PM +0200, Alex Dupre wrote: > Alex Kozlov ha scritto: > >> It's necessary if you don't want to use ccache only for 1% of the > >> buildworld process. > > I use CCACHE_NOHASH_SIZE_MTIME: > > "It's not necessary to use CCACHE_HASH_COMPILER" != "I use > CCACHE_NOHASH_SIZE_MTIME, so every compiler I use I will get always the > same result." Problem in make buildworld case is not compiler name. Problem is that compiler rebuild itself and mtime alway different. So I'm use switch exactly for this case and not depend on side effects CCACHE_HASH_COMPILER. Also later is undocumented. -- Adios ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Standardize NO_CCACHE flag and ccache definitions
Alex Kozlov ha scritto: It's necessary if you don't want to use ccache only for 1% of the buildworld process. I use CCACHE_NOHASH_SIZE_MTIME: "It's not necessary to use CCACHE_HASH_COMPILER" != "I use CCACHE_NOHASH_SIZE_MTIME, so every compiler I use I will get always the same result." -- Alex Dupre ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Standardize NO_CCACHE flag and ccache definitions
On Wed, Jun 18, 2008 at 05:05:42PM +0200, Alex Dupre wrote:
> Alex Kozlov ha scritto:
> > Don't use it for building ports. Actualy it's not necessary even for
> > make buildworld.
>
> It's necessary if you don't want to use ccache only for 1% of the
> buildworld process.
I use CCACHE_NOHASH_SIZE_MTIME:
if (getenv("CCACHE_HASH_COMPILER")) {
hash_file(args->argv[0]);
} else if (!getenv("CCACHE_NOHASH_SIZE_MTIME")) {
hash_int(st.st_size);
hash_int(st.st_mtime);
}
--
Adios
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Standardize NO_CCACHE flag and ccache definitions
Alex Kozlov ha scritto: Don't use it for building ports. Actualy it's not necessary even for make buildworld. It's necessary if you don't want to use ccache only for 1% of the buildworld process. -- Alex Dupre ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Standardize NO_CCACHE flag and ccache definitions
On Wed, Jun 18, 2008 at 11:16:42PM +1000, Edwin Groothuis wrote: > On Wed, Jun 18, 2008 at 03:01:58PM +0200, Alex Dupre wrote: > > Edwin Groothuis ha scritto: > > >Recently I've started to use devel/ccache again (sometimes it takes > > >a while before you understand how it works) and it works pretty > > >well, except for some ports which can't be build with it. For example > > >devel/cmake. > > > > I use ccache everywhere (world and ports) and I never found a port that > > doesn't compile with it (I have cmake, too). > > When building devel/cmake in a jail with ccache enabled it doesn't get > further than: > > ===> Configuring for cmake-2.6.0 > - > CMake 2.6-0, Copyright (c) 2007 Kitware, Inc., Insight Consortium > C compiler on this system is: /usr/local/libexec/ccache/world-cc -O2 > -fno-strict-aliasing -pipe > C++ compiler on this system is: /usr/local/libexec/ccache/world-c++ -O2 > -fno-strict-aliasing -pipe > [...] > CMake has bootstrapped. Now run make. > ===> Building for cmake-2.6.0 > Scanning dependencies of target cmsys > [ 0%] Building C object Source/kwsys/CMakeFiles/cmsys.dir/ProcessUNIX.o > [ 0%] Building C object Source/kwsys/CMakeFiles/cmsys.dir/Base64.o > [ 0%] Building C object Source/kwsys/CMakeFiles/cmsys.dir/MD5.o > [ 1%] Building C object Source/kwsys/CMakeFiles/cmsys.dir/Terminal.o > [ 1%] Building C object Source/kwsys/CMakeFiles/cmsys.dir/System.o > [ 1%] Building C object Source/kwsys/CMakeFiles/cmsys.dir/String.o > [ 2%] Building CXX object Source/kwsys/CMakeFiles/cmsys.dir/Directory.o > [ 2%] Building CXX object Source/kwsys/CMakeFiles/cmsys.dir/DynamicLoader.o > [ 2%] Building CXX object Source/kwsys/CMakeFiles/cmsys.dir/Glob.o > [ 3%] Building CXX object > Source/kwsys/CMakeFiles/cmsys.dir/RegularExpression.o > [ 3%] Building CXX object Source/kwsys/CMakeFiles/cmsys.dir/SystemTools.o > [ 3%] Building CXX object > Source/kwsys/CMakeFiles/cmsys.dir/CommandLineArguments.o > [ 4%] Building CXX object Source/kwsys/CMakeFiles/cmsys.dir/Registry.o > [ 4%] Building CXX object Source/kwsys/CMakeFiles/cmsys.dir/IOStream.o > [ 4%] Building CXX object > Source/kwsys/CMakeFiles/cmsys.dir/SystemInformation.o > Linking CXX static library libcmsys.a > Error running link command: No such file or directory > *** Error code 2 > > This happens with ccache, without ccache it doesn't. > > There are a couple of others which I can't recall right now. /usr/local/libexec/ccache/world-c++ sets CCACHE_HASH_COMPILER Don't use it for building ports. Actualy it's not necessary even for make buildworld. -- Adios ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Standardize NO_CCACHE flag and ccache definitions
Edwin Groothuis ha scritto: ===> Configuring for cmake-2.6.0 - CMake 2.6-0, Copyright (c) 2007 Kitware, Inc., Insight Consortium C compiler on this system is: /usr/local/libexec/ccache/world-cc -O2 -fno-strict-aliasing -pipe C++ compiler on this system is: /usr/local/libexec/ccache/world-c++ -O2 -fno-strict-aliasing -pipe This is not correct, it shouldn't use world-c++. This is mine: CMake 2.6-0, Copyright (c) 2007 Kitware, Inc., Insight Consortium C compiler on this system is: cc -O2 -fno-strict-aliasing -pipe -march=athlon-mp C++ compiler on this system is: c++ -O2 -fno-strict-aliasing -pipe -march=athlon-mp [...] [ 4%] Building CXX object Source/kwsys/CMakeFiles/cmsys.dir/SystemInformation.o Linking CXX static library libcmsys.a Error running link command: No such file or directory *** Error code 2 Mine: [...] [ 4%] Building CXX object Source/kwsys/CMakeFiles/cmsys.dir/Registry.o [ 4%] Building CXX object Source/kwsys/CMakeFiles/cmsys.dir/IOStream.o [ 4%] Building CXX object Source/kwsys/CMakeFiles/cmsys.dir/SystemInformation.o Linking CXX static library libcmsys.a [ 4%] Built target cmsys Scanning dependencies of target cmsysTestDynload [ 5%] Building C object Source/kwsys/CMakeFiles/cmsysTestDynload.dir/testDynload.o Linking C shared module libcmsysTestDynload.so [ 5%] Built target cmsysTestDynload [...] I think you should check why it's failing for you, but it's not a common behavior, so I don't see the reason to handle NOCCAHE inside the ports infrastructure. -- Alex Dupre ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Standardize NO_CCACHE flag and ccache definitions
Edwin Groothuis ha scritto: Recently I've started to use devel/ccache again (sometimes it takes a while before you understand how it works) and it works pretty well, except for some ports which can't be build with it. For example devel/cmake. I use ccache everywhere (world and ports) and I never found a port that doesn't compile with it (I have cmake, too). -- Alex Dupre ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Standardize NO_CCACHE flag and ccache definitions
On Wed, Jun 18, 2008 at 03:11:43PM +0200, Alex Dupre wrote: > Edwin Groothuis ha scritto: > >Unfortunately /etc/make.conf is read before the ports Makefile is > >read, so this in /etc/make.conf isn't going to work anymore: > > > > .if !defined(NO_CCACHE) > > CC=/usr/local/libexec/ccache/cc > > CXX=/usr/local/libexec/ccache/c++ > > CPP=/usr/local/libexec/ccache/cpp > > CCACHE_DIR=/usr/local/ccache > > .endif > > This is not the recommended way to use ccache. Look at the port's > documentation. True. It's also not the ones I use on the jails: [/usr/ports/devel/cmake] [EMAIL PROTECTED]>cat /etc/make.conf [/usr/ports/devel/ccache] [EMAIL PROTECTED]>cat /etc/make.conf WRKDIRPREFIX= /var/ports DISTDIR=/var/ports/distfiles PACKAGES= /var/ports/packages PACKAGE_BUILDING= yes FTP_PASSIVE_MODE= yes .if !defined(NOCCACHE) CC=/usr/local/libexec/ccache/world-cc CXX=/usr/local/libexec/ccache/world-c++ .endif # added by use.perl 2008-06-18 13:13:07 PERL_VER=5.8.8 PERL_VERSION=5.8.8 [/usr/ports/devel/cmake] [EMAIL PROTECTED]>export PATH=/usr/local/libexec/ccache:$PATH [/usr/ports/devel/cmake] [EMAIL PROTECTED]>export CCACHE_PATH=/usr/bin:/usr/local/bin [/usr/ports/devel/cmake] [EMAIL PROTECTED]>make clean build ===> Cleaning for cmake-2.6.0 ===> Extracting for cmake-2.6.0 [...] -- The C compiler identification is GNU -- The CXX compiler identification is GNU -- Check for working C compiler: /usr/local/libexec/ccache/world-cc -- Check for working C compiler: /usr/local/libexec/ccache/world-cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /usr/local/libexec/ccache/world-c++ -- Check for working CXX compiler: /usr/local/libexec/ccache/world-c++ -- works [...] [ 4%] Building CXX object Source/kwsys/CMakeFiles/cmsys.dir/SystemInformation.o Linking CXX static library libcmsys.a Error running link command: No such file or directory *** Error code 2 Edwin -- Edwin Groothuis |Personal website: http://www.mavetju.org [EMAIL PROTECTED]| Weblog: http://www.mavetju.org/weblog/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Standardize NO_CCACHE flag and ccache definitions
Edwin Groothuis ha scritto: Unfortunately /etc/make.conf is read before the ports Makefile is read, so this in /etc/make.conf isn't going to work anymore: .if !defined(NO_CCACHE) CC=/usr/local/libexec/ccache/cc CXX=/usr/local/libexec/ccache/c++ CPP=/usr/local/libexec/ccache/cpp CCACHE_DIR=/usr/local/ccache .endif This is not the recommended way to use ccache. Look at the port's documentation. -- Alex Dupre ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Standardize NO_CCACHE flag and ccache definitions
On Wed, Jun 18, 2008 at 03:01:58PM +0200, Alex Dupre wrote: > Edwin Groothuis ha scritto: > >Recently I've started to use devel/ccache again (sometimes it takes > >a while before you understand how it works) and it works pretty > >well, except for some ports which can't be build with it. For example > >devel/cmake. > > I use ccache everywhere (world and ports) and I never found a port that > doesn't compile with it (I have cmake, too). When building devel/cmake in a jail with ccache enabled it doesn't get further than: ===> Configuring for cmake-2.6.0 - CMake 2.6-0, Copyright (c) 2007 Kitware, Inc., Insight Consortium C compiler on this system is: /usr/local/libexec/ccache/world-cc -O2 -fno-strict-aliasing -pipe C++ compiler on this system is: /usr/local/libexec/ccache/world-c++ -O2 -fno-strict-aliasing -pipe [...] CMake has bootstrapped. Now run make. ===> Building for cmake-2.6.0 Scanning dependencies of target cmsys [ 0%] Building C object Source/kwsys/CMakeFiles/cmsys.dir/ProcessUNIX.o [ 0%] Building C object Source/kwsys/CMakeFiles/cmsys.dir/Base64.o [ 0%] Building C object Source/kwsys/CMakeFiles/cmsys.dir/MD5.o [ 1%] Building C object Source/kwsys/CMakeFiles/cmsys.dir/Terminal.o [ 1%] Building C object Source/kwsys/CMakeFiles/cmsys.dir/System.o [ 1%] Building C object Source/kwsys/CMakeFiles/cmsys.dir/String.o [ 2%] Building CXX object Source/kwsys/CMakeFiles/cmsys.dir/Directory.o [ 2%] Building CXX object Source/kwsys/CMakeFiles/cmsys.dir/DynamicLoader.o [ 2%] Building CXX object Source/kwsys/CMakeFiles/cmsys.dir/Glob.o [ 3%] Building CXX object Source/kwsys/CMakeFiles/cmsys.dir/RegularExpression.o [ 3%] Building CXX object Source/kwsys/CMakeFiles/cmsys.dir/SystemTools.o [ 3%] Building CXX object Source/kwsys/CMakeFiles/cmsys.dir/CommandLineArguments.o [ 4%] Building CXX object Source/kwsys/CMakeFiles/cmsys.dir/Registry.o [ 4%] Building CXX object Source/kwsys/CMakeFiles/cmsys.dir/IOStream.o [ 4%] Building CXX object Source/kwsys/CMakeFiles/cmsys.dir/SystemInformation.o Linking CXX static library libcmsys.a Error running link command: No such file or directory *** Error code 2 This happens with ccache, without ccache it doesn't. There are a couple of others which I can't recall right now. Edwin -- Edwin Groothuis |Personal website: http://www.mavetju.org [EMAIL PROTECTED]| Weblog: http://www.mavetju.org/weblog/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Standardize NO_CCACHE flag and ccache definitions
Hello,
Recently I've started to use devel/ccache again (sometimes it takes
a while before you understand how it works) and it works pretty
well, except for some ports which can't be build with it. For example
devel/cmake.
To prevent everybody from having to re-invent the wheel, we could
introduce a NO_CCACHE flag in the affected ports Makefile:
NO_CCACHE=yes
Unfortunately /etc/make.conf is read before the ports Makefile is
read, so this in /etc/make.conf isn't going to work anymore:
.if !defined(NO_CCACHE)
CC=/usr/local/libexec/ccache/cc
CXX=/usr/local/libexec/ccache/c++
CPP=/usr/local/libexec/ccache/cpp
CCACHE_DIR=/usr/local/ccache
.endif
So, what is wisdom? Maybe this:
Having a flag in /etc/make.conf to indicate you want to use
devel/ccache:
WANT_CCACHE=yes
And in the ports Makefile you could have:
NO_CCACHE=yes
And in bsd.port.mk before the inclusion of bsd.gcc.mk:
.if defined(WANT_CCACHE) && !defined(NO_CCACHE)
CC?=${LOCALBASE}/libexec/ccache/cc
CXX?= ${LOCALBASE}/libexec/ccache/c++
CPP?= ${LOCALBASE}/libexec/ccache/cpp
CCACHE_DIR?=${LOCALBASE}/ccache
.endif
How about this approach?
Edwin
--
Edwin Groothuis |Personal website: http://www.mavetju.org
[EMAIL PROTECTED]| Weblog: http://www.mavetju.org/weblog/
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
