RE: another devenv problem

It will improve your full re-build speeds. However, it will 
make the incremental relink-relaunch cycle more painful. Also, 
we found, just when doing one of these gang files per library, 
that there are many files with dependencies on actually being 
a separate translation unit, because of naming of statics, or 
macros, or helper classes, or whatever.

We got this mechanism working, and used it for over a year, 
but we've stopped doing it now. Full builds are less common 
than single-file re-builds.

Cheers,

			/ h+


-----Original Message-----
From: [email protected]
[mailto:[email protected]]On Behalf Of
Lewin, Gareth
Sent: Monday, November 15, 2004 3:05 PM
To: [email protected]
Subject: RE: [GD-Windows] another devenv problem


Well you could create a master .cpp file, #include all the .cc files in
it, and make all of them non-build files. It will work, and as a side
issue it will improve you build speeds.

_________________________________________
Gareth Lewin - http://www.garethlewin.com

"Facts are useless. You can use facts to prove anything that's even
remotely true. Facts shmacts!" -- Homer Jay Simpson. 

> -----Original Message-----
> From: Chris Raine [mailto:[email protected]] 
> Sent: Monday, November 15, 2004 4:11 PM
> To: [email protected]
> Subject: RE: [GD-Windows] another devenv problem
> 
> On Mon, 2004-11-15 at 18:35, Jon Watte wrote:
> > The .sln and .vcproj files are text files. You can open 
> them and edit 
> > them. I suggest saving a copy of your .vcproj, then 
> changing one file 
> > and saving, then running diff on the project file. When 
> done, write a 
> > perl script to apply the same change for all files.
> > 
> > It is also sometimes possible to select more than one file 
> and make a 
> > change on many files at the same time in the property 
> pages. I don't 
> > recall whether this is one of those cases.
> > 
> > Cheers,
> > 
> > 			/ h+
> > 
> 
> I had also thought about writing a perl script, which parses 
> the devenv project files. But my perl-foo is too limited to 
> do such a task. And maintaining another piece of crypto-code 
> for every new devenv release (this unix code is going to 
> stick with us for a while) .... yuck.
> 
> I guess either living with the second solution (that actually 
> works - I feel quite stupid now), or going for SCons 
> (www.scons.org) or this boost-jam seems the only way to go. 
> 
> Thanks for the tip.
> 
> --
> regards,
> Chris Raine 
> 
> 


-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
_______________________________________________
Gamedevlists-windows mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_idU5



-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
_______________________________________________
Gamedevlists-windows mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=555