On Tue, Jun 5, 2012 at 4:13 AM, Bjoern Michaelsen
wrote:
> Finished a master build:
>
> 1.2G workdir/unxlngx6.pro/Dep/
>
> of a:
>
> 5.4G .
>
> total. Yeah, thats a bit much. Theres:
>
> 644M workdir/unxlngx6.pro/Dep/CxxObject
>
> which can likely be compressed withou
On 2012-06-05 11:14, Bjoern Michaelsen wrote:
Yes, but in this case buildspeed and disksize are likely a tradeoff.
Making the build smaller will likely make it slower.
Not necessarily. On rotating disks, it can be cheaper to compress
because it results in less IO.
Disclaimer: http://www.per
On Mon, Jun 04, 2012 at 08:15:19PM +0200, Rob Snelders wrote:
> I want to add that the buildspeed and disksize does matter. Not
> everybody who wants to help can afford the newest machines.
Yes, but in this case buildspeed and disksize are likely a tradeoff. Making the
build smaller will likely ma
On Mon, Jun 04, 2012 at 11:35:44PM +0200, Bjoern Michaelsen wrote:
> On Mon, Jun 04, 2012 at 06:53:56PM +0100, Michael Meeks wrote:
> > Sigh; true - it'll mostly speedup build time then; then again we could
> > filter them during / after generation I suppose.
>
> But thats not the big part - a
On Mon, Jun 04, 2012 at 06:53:56PM +0100, Michael Meeks wrote:
> Sigh; true - it'll mostly speedup build time then; then again we could
> filter them during / after generation I suppose.
But thats not the big part - as a:
du -h $(WORKDIR)/Dep/*
will confirm -- CxxObjects is rather large .
Hi All,
I want to add that the buildspeed and disksize does matter. Not
everybody who wants to help can afford the newest machines.
--
Greetings,
Rob Snelders
Op 04-06-12 19:53, Michael Meeks schreef:
Hi Bjoern,
On Mon, 2012-06-04 at 17:19 +0200, Bjoern Michaelsen wrote:
But concat-deps is
Hi Bjoern,
On Mon, 2012-06-04 at 17:19 +0200, Bjoern Michaelsen wrote:
> But concat-deps is _after_ the creation dep files of the objects (which will
> then still be huge).
Sigh; true - it'll mostly speedup build time then; then again we could
filter them during / after generation I suppo
On Mon, Jun 04, 2012 at 06:38:46PM +0200, Michael Stahl wrote:
> who cares how big the files are (disk is cheap), the relevant metric is:
> how many seconds does make need to parse them?
> ...
> yes, but keep in mind that variables in the dep files will need to be
> expanded by make, which will lik
On 2012-06-04 18:38, Michael Stahl wrote:
sadly AFAIK make cannot include compressed files...
True.
But it should be possible to either (a) teach it that trick or (b) check
if the filesystem supports it, and if so, activate per-file compression.
NTFS:
http://www.microsoft.com/resources/doc
On 04/06/12 17:19, Bjoern Michaelsen wrote:
> On Mon, Jun 04, 2012 at 03:56:41PM +0200, Lubos Lunak wrote:
>> On Friday 01 of June 2012, Michael Meeks wrote:
>>> IMHO we could - without significant loss of functionality reduce all
>>> those deps to a single stamp file (which we prolly install
On 2012-06-04 17:19, Bjoern Michaelsen wrote:
Note however, that every bit of added complexity to the build system
will bite you back one day. Currently the Deps are ~10% of the working
directory -- even if you reduce them by 90%(*),
(*) which you wont unless you gzip them (which is doable and
On Mon, Jun 04, 2012 at 03:56:41PM +0200, Lubos Lunak wrote:
> On Friday 01 of June 2012, Michael Meeks wrote:
> > And some thoughts on improving this; currently we add a ton of deps for
> > packages that are really internal and typically change en-masse or not
> > at all.
> >
> > eg. 'boos
On Friday 01 of June 2012, Michael Meeks wrote:
> And some thoughts on improving this; currently we add a ton of deps for
> packages that are really internal and typically change en-masse or not
> at all.
>
> eg. 'boost' - it is installed, and then ~never changes again - people
> don't
On Fri, 2012-06-01 at 12:10 +0200, Michael Stahl wrote:
> i remember the recent ICU upgrade breaking all kinds of stuff in an
> incremental build because the header timestamps were somehow wrong
I fixed that one since FWIW. Though we don't have any dependencies on
the output of the icu build-time
On Fri, Jun 1, 2012 at 5:10 AM, Michael Stahl wrote:
> On 01/06/12 11:16, Michael Meeks wrote:
>>
>> And some thoughts on improving this; currently we add a ton of deps for
>> packages that are really internal and typically change en-masse or not
>> at all.
>>
>> eg. 'boost' - it is in
On 01/06/12 11:16, Michael Meeks wrote:
>
> And some thoughts on improving this; currently we add a ton of deps for
> packages that are really internal and typically change en-masse or not
> at all.
>
> eg. 'boost' - it is installed, and then ~never changes again - people
> don't edit
And some thoughts on improving this; currently we add a ton of deps for
packages that are really internal and typically change en-masse or not
at all.
eg. 'boost' - it is installed, and then ~never changes again - people
don't edit a single boost header and expect a dependency cle
17 matches
Mail list logo
