For years, I've been placing all my projects and all my various 
include files in a single directory (CPP).  It's now quite large (and 
messy!), and I'm trying to convert my code to a newer compiler.  This 
new system seems to expect each project's source to exist in a separate 
directory structure, but I want all projects share my include files.
   I can't figure how to structure my sources so that I can use a single 
#include "stdafx.h" statement in my project's main source file.  A 
project's source stdafx.h file contains the following:
////////////////////////////////////////
#include <stdio.h>
#include <iostream>
#include <sstream>
#include <fstream>
#include <sstream>
#include <ostream>
#include <string>
#include <list>
#include <vector>
#include <map>
#include <set>
#include <bitset>
#include <algorithm>
#include <iomanip>
#include <io.h>
#include <stdlib.h>
#include <string.h>
#include <assert.h>
#include <direct.h>
#include <ctype.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <conio.h>

#include "myclass3.h"
#include "mylib2.h"
#include "myua2.h"
#include "myprint2.h"
using namespace std;
///////////////////////////////////////////
   
   This works, but I'm trying to place my own include files 
("myclass.h", etc.) in a different directory (/incl, for example) that 
can be referenced by many projects.  I've tried various things, such as:
#include "../incl/stdafx.h"
in my main code, but that doesn't work at all (the compiler can't find 
the stdafx.h file).
   My structure (which doesn't work) is:
/CPP
/CPP/hello01    (a project directory)
/CPP/incl       (directory for all include files)
/CPP/project02  {another project's directory)
[etc.]
   
   I'm unable to find any examples (by googling) that demonstrate how to 
use a single "stdafx.h" file in sources other than the directory in 
which the source files reside (or how to set up a common "include" 
directory).  It seems fundamental to multiple project development, but I 
just can't figure it out.  Please advise.  TIA

"Mike Copeland" <mrc2323@cox.net>
>   For years, I've been placing all my projects and all my various
> include files in a single directory (CPP).  It's now quite large (and
> messy!), and I'm trying to convert my code to a newer compiler.  This
> new system seems to expect each project's source to exist in a separate
> directory structure, but I want all projects share my include files.
>   I can't figure how to structure my sources so that I can use a single
> #include "stdafx.h" statement in my project's main source file.

Sounds unnatural.

stdafx.h normally serves a single purpose: precompiled header. And is 
specific for the project. For the sad reason that this far MS refused to 
give us precompiled header that can bve shared between projects in a 
solution. (anyone who konws a way please tell.)

So, having that the only good place of stdafx.h is the project's private dir 
for its includes (that may be its only dir that also has the .cpp files.) 
You can access includes for sharing from there either directly or via 
'include directories' option in the project.

And certainly instead of writing #include "stdafx.h" in your sources you 
just make it include via the 'focred include' option, where you can spell 
$(projectdir)stdafx.h or something like that, independently of all the other 
dirs.

>   I'm unable to find any examples (by googling) that demonstrate how to
> use a single "stdafx.h" file in sources other than the directory in
> which the source files reside (or how to set up a common "include"
> directory).

What's there to demonstrate? You can use any include filenames residing 
anywhere at all. The .pch is NOT created form a header, but from the file 
you mark for 'Create' option -- that is normally stdafx.cpp if you use the 
defaults. Then you shall have the same includes in the other files in the 
same order up to #pragma headerstop (or all in the created thing.)

So, for example you can name it stdafx_$(projectname).h and keep in that 
common directory.

Though it IMO makes no sense whatsoever, common dirs are for common files, 
and those that are used by a single project better kept there.

In your case I'd probably have two forced includes, one common and one 
project-specific, in that order.

In article <jr32jj$2b02$1@news.ett.com.ua>, pasa@lib.hu says...
>    stdafx.h normally serves a single purpose: precompiled header. And is 
> specific for the project.
>    So, having that the only good place of stdafx.h is the project's private dir 
> for its includes (that may be its only dir that also has the .cpp files.) 
> You can access includes for sharing from there either directly or via 
> 'include directories' option in the project.
>    And certainly instead of writing #include "stdafx.h" in your sources you 
> just make it include via the 'focred include' option, where you can spell 
> $(projectdir)stdafx.h or something like that, independently of all the other 
> dirs.
   
   How do I do that?  I don't understand this idiom.  8<{{
> 
> >   I'm unable to find any examples (by googling) that demonstrate how to
> > use a single "stdafx.h" file in sources other than the directory in
> > which the source files reside (or how to set up a common "include"
> > directory).
> 
> What's there to demonstrate? You can use any include filenames residing 
> anywhere at all. The .pch is NOT created form a header, but from the file 
> you mark for 'Create' option -- that is normally stdafx.cpp if you use the 
> defaults. Then you shall have the same includes in the other files in the 
> same order up to #pragma headerstop (or all in the created thing.)

   Well, I can't get that to work. <sigh>  I tried to specify a specific 
directory (/incl) that has all my common include files, but the compiler 
"can't see" this location from where it's doing the project compile.  I 
would have thought your statement here was so, but I cannot get the 
project stdafx.h include references to point to my /incl directory.  8
<{{
> 
> So, for example you can name it stdafx_$(projectname).h and keep in that 
> common directory.

   And how do I declare that specific name in my project's sources so 
the compiler actually sees that stdafx.h file?  This seems to be where 
I'm having difficulty: the M$ file system references.
 
> Though it IMO makes no sense whatsoever, common dirs are for common files, 
> and those that are used by a single project better kept there.

   Which what I'm trying to do.  As I work on multiple projects, I don't 
want to have to manage multiple instances of my common library include 
files as I change any one of them.  So, it makes sense that I keep the 
common files in one location, right?
> 
> In your case I'd probably have two forced includes, one common and one 
> project-specific, in that order.
> 
   Isn't this the way most C/C++ programmers set their system up?  Here 
I'm trying to (finally) do things "the right way", moreso than before.

"Mike Copeland" <mrc2323@cox.net>

>>    stdafx.h normally serves a single purpose: precompiled header. And is
>> specific for the project.
>>    So, having that the only good place of stdafx.h is the project's 
>> private dir
>> for its includes (that may be its only dir that also has the .cpp files.)
>> You can access includes for sharing from there either directly or via
>> 'include directories' option in the project.
>>    And certainly instead of writing #include "stdafx.h" in your sources 
>> you
>> just make it include via the 'focred include' option, where you can spell
>> $(projectdir)stdafx.h or something like that, independently of all the 
>> other
>> dirs.
>
>   How do I do that?  I don't understand this idiom.  8<{{

We're pretty much offtopic here, so please read the compiler options, most 
provide enough help on the GUI by just selecting it. And where you enter the 
option text, it shows available macros with their current value.

>> >   I'm unable to find any examples (by googling) that demonstrate how to
>> > use a single "stdafx.h" file in sources other than the directory in
>> > which the source files reside (or how to set up a common "include"
>> > directory).
>>
>> What's there to demonstrate? You can use any include filenames residing
>> anywhere at all. The .pch is NOT created form a header, but from the file
>> you mark for 'Create' option -- that is normally stdafx.cpp if you use 
>> the
>> defaults. Then you shall have the same includes in the other files in the
>> same order up to #pragma headerstop (or all in the created thing.)
>
>   Well, I can't get that to work. <sigh>  I tried to specify a specific
> directory (/incl) that has all my common include files, but the compiler
> "can't see" this location from where it's doing the project compile.  I
> would have thought your statement here was so, but I cannot get the
> project stdafx.h include references to point to my /incl directory.  8
> <{{

Well, everyone else can... If you actually tried setting the additinal 
include dir option, used up all internal diagnostics (/showincludes, most 
detailed build info, ...) and still no luck, try sysinternals' process 
monitor to see where the compiler attempts to open your files.

>> So, for example you can name it stdafx_$(projectname).h and keep in that
>> common directory.
>
>   And how do I declare that specific name in my project's sources so
> the compiler actually sees that stdafx.h file?  This seems to be where
> I'm having difficulty: the M$ file system references.

You configure that in project options that are saved to .vcxproj. And used 
by msbuild that drives the compilation.

In the solution explorer right click on the project -> properties -> a few 
hundred options...

>
>> Though it IMO makes no sense whatsoever, common dirs are for common 
>> files,
>> and those that are used by a single project better kept there.
>
>   Which what I'm trying to do.  As I work on multiple projects, I don't
> want to have to manage multiple instances of my common library include
> files as I change any one of them.  So, it makes sense that I keep the
> common files in one location, right?

Absolutely. :)

>>
>> In your case I'd probably have two forced includes, one common and one
>> project-specific, in that order.
>>
>   Isn't this the way most C/C++ programmers set their system up?  Here
> I'm trying to (finally) do things "the right way", moreso than before.

Dunno what most people do :)  Would guess most accept most of the defaults 
created by VS wizards.  That hardcode the #include, hardcode the name 
stdafx.h.  Probably okay as starting point.

For big solutions better use common .props. But it's advanced stuff, after 
one mastered the basic options.

On 06/11/12 12:20 PM, Mike Copeland wrote:
> In article<jr32jj$2b02$1@news.ett.com.ua>, pasa@lib.hu says...
>>     stdafx.h normally serves a single purpose: precompiled header. And is
>> specific for the project.
>>     So, having that the only good place of stdafx.h is the project's private dir
>> for its includes (that may be its only dir that also has the .cpp files.)
>> You can access includes for sharing from there either directly or via
>> 'include directories' option in the project.
>>     And certainly instead of writing #include "stdafx.h" in your sources you
>> just make it include via the 'focred include' option, where you can spell
>> $(projectdir)stdafx.h or something like that, independently of all the other
>> dirs.
>
>     How do I do that?  I don't understand this idiom.  8<{{

You should ask on a windows programming group, this is all tool rather 
than language related.

-- 
Ian Collins

On 11 kes=E4, 03:20, mrc2...@cox.net (Mike Copeland) wrote:
> =A0 =A0And how do I declare that specific name in my project's sources so
> the compiler actually sees that stdafx.h file?

Is there any reason to use precompiled headers? You know, you don't
have to use them.

Mike Copeland <mrc2323@cox.net> wrote:
> For years, I've been placing all my projects and all my various 
> include files in a single directory (CPP).  It's now quite large (and 
> messy!), and I'm trying to convert my code to a newer compiler.  This 
> new system seems to expect each project's source to exist in a separate 
> directory structure, but I want all projects share my include files.
>    I can't figure how to structure my sources so that I can use a single 
> #include "stdafx.h" statement in my project's main source file.  A 
> project's source stdafx.h file contains the following:
> ////////////////////////////////////////
> #include <stdio.h>
> #include <iostream>
> #include <sstream>
> #include <fstream>
> #include <sstream>
> #include <ostream>
> #include <string>
> #include <list>
> #include <vector>
> #include <map>
> #include <set>
> #include <bitset>
> #include <algorithm>
> #include <iomanip>
> #include <io.h>
> #include <stdlib.h>
> #include <string.h>
> #include <assert.h>
> #include <direct.h>
> #include <ctype.h>
> #include <sys/types.h>
> #include <sys/stat.h>
> #include <conio.h>
> 
> #include "myclass3.h"
> #include "mylib2.h"
> #include "myua2.h"
> #include "myprint2.h"
> using namespace std;
> ///////////////////////////////////////////
>    
>    This works, but I'm trying to place my own include files 
> ("myclass.h", etc.) in a different directory (/incl, for example) that 
> can be referenced by many projects.  I've tried various things, such as:
> #include "../incl/stdafx.h"
> in my main code, but that doesn't work at all (the compiler can't find 
> the stdafx.h file).
>    My structure (which doesn't work) is:
> /CPP
> /CPP/hello01    (a project directory)
> /CPP/incl       (directory for all include files)
> /CPP/project02  {another project's directory)
> [etc.]
>    
>    I'm unable to find any examples (by googling) that demonstrate how to 
> use a single "stdafx.h" file in sources other than the directory in 
> which the source files reside (or how to set up a common "include" 
> directory).  It seems fundamental to multiple project development, but I 
> just can't figure it out.  Please advise.  TIA

I would suggest that you factor out your common source code into a static
library, that can be used by your other projects.
(make a new VS project of type static library)

Example:

File structure:

-- new static library
libcommon/libcommon.h   --  The main header of your New library
libcommon/commonheader1.h
libcommon/commonheader2.h
libcommon/commonheader2.h
....
libcommon/commonsource1.cpp
libcommon/commonsource2.cpp
libcommon/commonsource3.cpp
....

-- project using static library
project1/stdafx.h   --  precompiled header if needed
project1/header1.h
project1/header2.h
....
project1/source1.cpp
project1/source2.cpp
....
project1/stdafx.cpp

Files:

libcommon/libcommon.h
------------------------
#include "commonheader1.h"
#include "commonheader2.h"
#include "commonheader3.h"
....
------------------------

project1/stdafx.h
------------------------
#include "../libcommon.h"
------------------------

project1/source1.cpp
------------------------
#include "stdafx.h"
------------------------

"Krice" <paulkp@mbnet.fi>

>Is there any reason to use precompiled headers? You know, you don't
>have to use them.

Reducing compile time to 2-10% of the original looks like a pretty good 
reason to me.

Also some win system includes (maybe even your own) use #import to include 
some COM component. That is incompatible with multiprocessor parallel build. 
But if you put those headers in the procompiled header, that problem is 
gone.