«

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" <>
> 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$>, 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" <>

>> 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$>, 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ä, 03:20, mrc2...@cox.net (Mike Copeland) wrote:
> * *And 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 <> 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" <>

>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.