[chromium-dev] Re: Has your computer melted?
I've heard it claimed that the reason it's undocumented in VS2005 is
because there are bugs that mean it can do the wrong thing from time
to time--perhaps this is why some people are seeing errors.
It's documented (and supposed to work properly) in VS2008, and I've
been using it for building chromium for many months without any
apparent problems. The ability to do parallel builds of single
projects (rather than merely build projects in parallel) makes it
quite desirable, IMO.
2009/1/6 Brett Wilson bre...@chromium.org:
On Jan 5, 4:32 pm, Brett Wilson bre...@chromium.org wrote:
I just checked in a change to use /MP for all compiles, which is a
secret undocumented flag that does parallel compiles within each
project.
Please let me know of your computer melts or becomes unusable during a
compile. It should more efficiently use all of your CPUs when doing
regular Visual Studio builds (it will have no effect on
IncrediBuilds). You can remove it from essential.vsprops if it's
causing problems.
We tested on Carlos' 2-processor system and it pegged the CPU more,
although it's not clear if it's a lot faster than before. On my
4-processor system, a build of just chrome_exe and all of it's
dependencies went from 25 to 16 minutes after using this flag. So if
you hate IncrediBuild, life might actually be tolerable without it for
fast systems.
This was backed out earlier today due to weird errors, especially with
regard to linking and symbols. Some people have also reported that
Visual Studio can think everything is out of date and rebuilds when
it's not necessary.
If you would like to keep trying this change out, do this locally:
http://chrome-svn/viewvc/chrome/trunk/src/build/internal/essential.vsprops?r1=7533r2=7573
and restart Visual Studio.
Brett
--
char a[9],*p=a;main(c,V)char**V;{char*v=c0?1[V]:V;if(c)for(;(c=*v)93^
c;p+=!(62^c)-!(60^c),*p+=!(43^c)-!(45^c),44^c||read(0,p,1),46^c||putchar(*p)
,91^c||(v=*p?main(-1,v+1),v-1:main(0,v)),++v);else for(;c+=!(91^*v)-!(93^*v)
;++v);return v;} /* drpi...@gmail.combrainf*** program as argv[1] */
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: Issue 3080: {Get/Set}CurrentDirectory()
Their fixed-size nature is also pretty lousy. That is to say, they're
limited to MAX_PATH with no provision for long-filenames (longer than
MAX_PATH that is). They're not the only place that Win32 has such
restrictions, but they're one of the harder to avoid ones.
2008/10/6 Darin Fisher [EMAIL PROTECTED]:
I added a comment in the bug, which explains why I think those functions are
to be avoided. There may be other good reasons too!
-Darin
On Sun, Oct 5, 2008 at 8:27 PM, enchantingBlu [EMAIL PROTECTED]
wrote:
Hi,
A bug has been filed lately for replacing GetCurrentDirectory and
SetCurrentDirectory. No furthur information is provided. I assume the
problem with these would be about DOS kind of naming and full path
naming of the directory paths? Also, with the cross platform work
going on, these will be more or less consumed anyway. But if anyone
has any real issues with these then lets discuss this here or get the
bug out of the backlog?
thanks,
Zaki
--
char a[9],*p=a;main(c,V)char**V;{char*v=c0?1[V]:V;if(c)for(;(c=*v)93^
c;p+=!(62^c)-!(60^c),*p+=!(43^c)-!(45^c),44^c||read(0,p,1),46^c||putchar(*p)
,91^c||(v=*p?main(-1,v+1),v-1:main(0,v)),++v);else for(;c+=!(91^*v)-!(93^*v)
;++v);return v;} /* [EMAIL PROTECTED]brainf*** program as argv[1] */
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Chromium-dev group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---
