#pragma for include directories
Peter Carlson
myprogram.c
#include "speex_2/include/speex/speex.h"
However speex.h has it's own includes that also look the same:
#include "speex/speex_bits.h" which is relative to the include folder
I know I can add speex2/include to the search directories for the IDE,
but I dont necessarily want it for all projects. is there a pragma
comment (or something similar) that will let me add a serach directory
for one project?
#pragma comment (compiler, "/dir:c:\projects\myprog\speex_2\include")
Thanks
Peter
Tom Serface
You can set this up in the projects where you will use it in the project
settings under C++/General/Additional Include Directories.
Tom
"Peter Carlson" <peter@h_o_w_u_d_o_d_a_t.com> wrote in message
news:uetCkr0t...@TK2MSFTNGP03.phx.gbl...
Jeff…Relf
on a per project basis Mr. Carlson.
For better documentation, I recommend this:
#include \
"C:\\Program Files\\Microsoft DirectX SDK (December 2005)\\Include\\DDraw.H"
#pragma comment( lib \
, "C:\\Program Files\\Microsoft DirectX SDK (December 2005)\\" \
"Lib\\x86\\DDraw.LIB")
Jeff…Relf
you can set the " libs/includes " path in a .H file.
e.g. From " www.Cotse.NET/users/jeffrelf/X.CPP ":
#define Quote_It( It ) #It
#define DD_Path( __X ) Quote_It( \
C:\\Program Files\\Microsoft DirectX SDK (December 2005)\\__X )
#include DD_Path( Include\\DDraw.H )
#pragma comment( lib , DD_Path( Lib\\x86\\DDraw.LIB ) )
David Wilkinson
Not sure if everyone agrees, but I find your habit of constantly
changing the subject of a thread very distracting.
I also disagree with your recommendation. IMHO, paths like the above
should go in the VC directory settings. Otherwise, if you move the
project to a different computer, then it will not compile unless the
DirectX SDK has been installed in the above location.
--
David Wilkinson
Visual C++ MVP
Jeff…Relf
not a solution-specific one, much less IDE-specific.
Suppose someone links to a .CPP file... which SDK was he using ?
Suppose you've downloaded multiple SDKs,
which one do you want with which projects ?
e.g., from " www.Cotse.NET/users/jeffrelf/Games.CPP ":
#define DD_Path( __X ) Quote_It( \
C:\\Program Files\\Microsoft DirectX SDK (December 2005)\\__X )
#include DD_Path( Include\\DDraw.H )
#pragma comment( lib , DD_Path( Lib\\x86\\DDraw.LIB ) )
#pragma comment( lib , DD_Path( Lib\\x86\\DXguid.LIB ) )
#include DD_Path( Include\\DInput.H )
#pragma comment( lib , DD_Path( Lib\\x86\\DInput8.LIB ) )
#include DD_Path( Include\\Dxerr8.H )
#pragma comment( lib , DD_Path( Lib\\x86\\Dxerr8.LIB ) )
I'm glad you don't like the way I change titles, David_Wilkinson,
because I don't like the way you fail to make the title relevent
to the body of the post. This is called " cascading ":
> >>> >
> >>> > >>
> >>> > >> >
> >>> > >> > >>
> >>> > >> > >> >>>
> >>> > >> > >>
> >>> > >>
> >>>
Cascaders are several notches below those who are
either too lazy to too ignorant to post relevent titles,
as users " SHOULD " [ sic ] according to RFC 1036.
Do you also slur your speach when talking ? I have to wonder.
I expect this from Google Groups newbies,
not from a " Visual C++ MVP ".
From " www.FAQs.ORG/rfcs/rfc1036.html
" 2.1.4. Subject
The " Subject " line ( formerly " Title " )
tells what the message is about.
It SHOULD be suggestive enough of
the contents of the message to enable a reader
to make a decision whether to read the message
based on the subject alone. "
From " www.Usenet-Fr.NET/fr-chartes/son-of-rfc1036.2.html
" If the poster determines that
the topic of the followup differs significantly
from what is described in the subject,
a new, more descriptive, subject SHOULD be substituted... ".
David Wilkinson
Jeff:
Maybe your method works for you, but for me having code that can be
moved between different machines, and between different versions of the
compiler, is more important than having different SDK's for different
projects.
As to changing the subject line, it would seem from your recent posts
that you do this routinely, which is certainly not the usenet norm.
Maybe there might be exceptions in very long threads, but for me, either
a response is relevant (keep the title) or it isn't (start a new
thread). In this case, your response to Peter Carlson was hardly
relevant, because you considered external SDK paths rather than paths to
files within the project. I read these groups several times a day, and
when I see an unread response post, I look at the subject and say to
myself "Ah yes, that is the thread about ...". Constant changing of the
subject line breaks that association.
Just my opinions...
Jeff…Relf
you ( David Wilkinson ) didn't even grasp the issue at hand.
Suppose you had a web link to a .CPP file,
Where in that file could I see the SKDs that you're using ?
Must I download your VCComponents.DAT
and load it into my copy of VS2005, overriding my settings ?
This, from " www.Cotse.NET/users/jeffrelf/Games.CPP ",
makes it clear, not your VCComponents.DAT :
#define DD_Path( __X ) Quote_It( \
C:\\Program Files\\Microsoft DirectX SDK (December 2005)\\__X )
#include DD_Path( Include\\DDraw.H )
#pragma comment( lib , DD_Path( Lib\\x86\\DDraw.LIB ) )
#pragma comment( lib , DD_Path( Lib\\x86\\DXguid.LIB ) )
#include DD_Path( Include\\DInput.H )
#pragma comment( lib , DD_Path( Lib\\x86\\DInput8.LIB ) )
#include DD_Path( Include\\Dxerr8.H )
#pragma comment( lib , DD_Path( Lib\\x86\\Dxerr8.LIB ) )
You told me:
" As to changing the subject line, it would seem from your recent posts
that you do this routinely, which is certainly not the usenet norm. ".
Laziness and ignorance ( e.g. cascading ) are the norm on Usenet,
so I'm sure you feel right at home.
Why did you quote my whole post ?
Aren't you too lazy to paraphrase ? I think so.
I hate scrolling down all the time for newbies like you.
You told me:
" ...either a response is relevant ( keep the title )
or it isn't ( --> start a new thread <-- ). ".
I wish you could see the steam coming out of my ears right now.
Look at this screenshot: " www.Cotse.NET/users/jeffrelf/Phy_R_TXT.PNG ".
Do you see the " sub thread " ? starting with the most recent, it's:
David_Wilkinson u$hhgY$tHHA...@TK2MSFTNGP03.phx.gbl
Jeff…Relf Jeff_Relf_2007_...@Cotse.NET
David_Wilkinson #BKKCy9t...@TK2MSFTNGP04.phx.gbl
Jeff…Relf Jeff_Relf_2007_...@Cotse.NET
Peter_Carlson uetCkr0t...@TK2MSFTNGP03.phx.gbl
A subthread is the 5 most recent ancestors ( MIDs ) of a post.
How was the subthread broken by the fact that I, unlike you,
took the time to post meaningful titles ? Answer me, damn it ! !
Why are your MIDs so meaningless ?
I'm surprised you're not using Google Groups.
Tom Serface
There is a setting in the project properties for additional include
directories that can be used for this sort of thing. That way you don't
pollute your whole IDE set up with a bunch of folders that are only being
used for specific projects.
Tom
"Jeff…Relf" <Jeff...@Yahoo.COM> wrote in message
news:Jeff_Relf_2007_...@Cotse.NET...
Tom Serface
have their IDE set up the same as you.
Tom
"Jeff…Relf" <Jeff...@Yahoo.COM> wrote in message
news:Jeff_Relf_2007_...@Cotse.NET...
Tom Serface
David makes a good point. It's easy enough to put something like
..\..\mylib\something.h into the project settings. That way if the whole
folder structure is moved to another computer it stays in tact. Your idea
would work, it's just a different direction and I can understand how some
would find it more difficult to maintain.
Tom
"Jeff…Relf" <Jeff...@Yahoo.COM> wrote in message
news:Jeff_Relf_2007_...@Cotse.NET...
Jeff…Relf
" David makes a good point. It's easy enough to put something like
How come you and David didn't understand Peter when he asked:
" Is there a pragma comment ( or something similar )
that will let me add a serach directory for one project ?
" #pragma comment ( compiler
He didn't say he wanted it for 2 projects,
he didn't say he wanted it for the whole solution,
yet you gentlemen tell him to provide it for the entire IDE.
When posting a web-link to a .CPP file,
how is the user supposed to know what's in your IDE settings ?
I don't know about you but, as a professonal coder,
I've been using relative paths constantly, ever since 1981,
I think the concept is getting familiar to me now.
Relative path or not, this does what Peter wanted:
#define Quote_It( It ) #It
#define Speex_2( __X ) Quote_It( \
C:\\projects\\myprog\\speex_2\\include\\__X )
After that, all he has to do is:
#include Speex_2( speex/speex.h )
#include Speex_2( speex/speex_bits.h )
Are you gentlemen laying down the law or providing solutions ?
I wonder. ( And yes, I'be been using " #define " since 1981 )
Andrew McDonald
> Jeff.Relf wrote:
>> I doubt you can set the " includes " path on a per project basis Mr.
>> Carlson. For better documentation, I recommend this:
>>
>> #include \
>> "C:\\Program Files\\Microsoft DirectX SDK (December
>> 2005)\\Include\\DDraw.H"
>>
>> #pragma comment( lib \
>> , "C:\\Program Files\\Microsoft DirectX SDK (December 2005)\\" \
>> "Lib\\x86\\DDraw.LIB")
>
> Jeff:
>
> Not sure if everyone agrees, but I find your habit of constantly changing
> the subject of a thread very distracting.
Agreed, it's made it awkward to look at this newgroup over the last few
days.
> I also disagree with your recommendation. IMHO, paths like the above
> should go in the VC directory settings. Otherwise, if you move the project
> to a different computer, then it will not compile unless the DirectX SDK
> has been installed in the above location.
Agreed again. This would completely break the codebase at my company, where
for various reasons different people working on the same project happen to
use different revisions of the DirectX SDK. IMO large SDKs which are
installed on the developer's system should be set up in their VS options,
and smaller ones which may only be referenced as part of the project
codebase should have their relative paths specified in the project
properties, as Tom said in the first reply.
--
Andy
Tom Serface
directories in th project file is another way to add it "to one project". My
suggestion was just another way to accomplish it. I think you'll find
people around here offering up all kinds of opinions about program style.
At the end of the day you're the only one editing your own code so you get
to make the final determination about what goes in there (so long as it
compiles of course).
Tom
"Jeff…Relf" <Jeff...@Yahoo.COM> wrote in message
news:Jeff_Relf_2007_...@Cotse.NET...
Jeff…Relf
He wants an include path for --> Some but Not all <-- projects.
Is this an unreasonable demand ?
Suppose he wants this path for project V, on drive V
as well as for project X on drive X.
Tom, Wilkinson and you ( Andrew McDonald ) basically told him:
" Tough biscuits, you have to set it in your IDE and then
--> Instruct <-- everyone else to do the same.
or else make it relative to... to... some thing-a-ma-bob. ".
Putting an " includes " path in your .CPP file makes it
extremly obvious to all concerned exactly what it is yer including.
No need to " intruct " people, no mystery folders.
Just one web link to the .CPP file makes everything obvious.
For Peter ( not you guys, think about Pete ) it could be:
#define Quote_It( It ) #It
#define Speex_2( __X ) Quote_It( \
L:\\projects\\myprog\\speex_2\\include\\__X )
and then:
Jeff…Relf
for some ( but not all ) of his projects, you ( Tom ) told me:
" There is a setting in [ Project --> right-click --> Properties ]
for additional include directories... ".
Where ? Are you referring to:
" Properties --> Common Properties --> References --> Add Path " ?
I only see " includes " paths for:
1. All solutions and projects ( scope: IDE, top root ).
2. A relative path for one and only one project,
not two projects, especially not two projects in different IDEs.
Putting the includes path in the .CPP file, like this:
#define Quote_It( It ) #It
#define Speex_2( __X ) Quote_It( \
L:\\projects\\myprog\\speex_2\\include\\__X )
and then this:
#include Speex_2( speex/speex.h )
#include Speex_2( speex/speex_bits.h )
gives you a scope that is super-IDE yet confined to a set of projects.
This way, you don't have to hope that your users are listening
as you ( hopefully ) instruct them as to the proper " includes " path.
Tom Serface
That's not true. To be clear, my suggestion was to set the extra include
paths in the project properties, not the IDE. And I didn't mention anything
about biscuits. You can also include the relative path as part of the
#include statement and that also makes it pretty obvious where the files
are. I just want to be clear, I think adding extra include paths (that you
wouldn't use for EVERY or MANY projects) in your IDE options is a bad idea.
You will eventually want someone else to maintain the code or you will want
to move it to another computer and you'll end up wondering why it won't
compile all of sudden.
Tom
"Jeff…Relf" <Jeff...@Yahoo.COM> wrote in message
news:Jeff_Relf_2007_...@Cotse.NET...
> Tom, Wilkinson and you ( Andrew McDonald ) basically told him:
Tom Serface
Open the project's properties.
Open Configuration
Open C/C++
Open General
It's on that dialog in 2005. I don't remember where it was on VC6.
Tom
"Jeff…Relf" <Jeff...@Yahoo.COM> wrote in message
news:Jeff_Relf_2007_...@Cotse.NET...
>
David Wilkinson
> Hi Jeff,
>
> That's not true. To be clear, my suggestion was to set the extra
> include paths in the project properties, not the IDE. And I didn't
> mention anything about biscuits. You can also include the relative path
> as part of the #include statement and that also makes it pretty obvious
> where the files are. I just want to be clear, I think adding extra
> include paths (that you wouldn't use for EVERY or MANY projects) in your
> IDE options is a bad idea. You will eventually want someone else to
> maintain the code or you will want to move it to another computer and
> you'll end up wondering why it won't compile all of sudden.
Dave/Jeff:
Just to be clear also, the reason I suggested putting the paths in the
IDE was because Jeff illustrated his method with paths from an SDK. I
personally would always put such paths in the IDE, because to do
otherwise would likely prevent compilation on another machine. I agree
that this does not allow different SDK versions for different projects,
but this is not something I do. But I agree with Tom that if there have
to be project-specific absolute paths, I would prefer to put them in the
project settings rather than the code. If the code required a particular
version of an SDK, I would likely put a comment (or warning) to that
effect, rather than hard-wiring some path that would likely not work on
a different machine.
OTOH, for paths to my own files, I keep all my production code in a
single directory structure, and always use relative addressing. This was
my suggestion to the OP, but I may have misunderstood the precise nature
of his question.
But this is just how I arrange my own projects; others may prefer a
different system.
Tom Serface
depending on our style.
Tom
"David Wilkinson" <no-r...@effisols.com> wrote in message
news:%23sWTXaM...@TK2MSFTNGP04.phx.gbl...
Peter Carlson
have torn a hole in the balance of the C universe.
I guess maybe I should have more clearly stated my original problem:
we have a lib (specifically speex). This lib has it's own directory
structure and project and builds just fine. However in order to use
this lib we must include it's header (obviously). Once we include the
main header has shown in myprogram.c, it attempts to include all the
other headers. These headers cannot be found because they are not in
the search path. I'd rather not edit the lib's files as that creates a
version nightmare when minor changes to the lib are released.
Hence the only real solutions are:
1. Add the directory to the ide's search path. This clutters up the ide
and creates other problems if there are many libs
2. Add the directory to this project's search path. I didn't know this
feature was available but thanks Tom for pointing it out. The only
drawback is it's not cross compiler but that's not what I asked for :)
Although I will need that in the future as we build on mac and linux
3. Add some form of a compiler comment - this does not seem to be
available.
So sorry for the controversy, my solution is simply to add it to the
project settings. And when we take our project to mac and linux I'll
have to figure out then what to do with gcc
Peter
David Wilkinson
> I had no idea my question would spark such controversy. I believe I
> have torn a hole in the balance of the C universe.
>
> I guess maybe I should have more clearly stated my original problem:
> we have a lib (specifically speex). This lib has it's own directory
> structure and project and builds just fine. However in order to use
> this lib we must include it's header (obviously). Once we include the
> main header has shown in myprogram.c, it attempts to include all the
> other headers. These headers cannot be found because they are not in
> the search path. I'd rather not edit the lib's files as that creates a
> version nightmare when minor changes to the lib are released.
>
> Hence the only real solutions are:
> 1. Add the directory to the ide's search path. This clutters up the ide
> and creates other problems if there are many libs
>
> 2. Add the directory to this project's search path. I didn't know this
> feature was available but thanks Tom for pointing it out. The only
> drawback is it's not cross compiler but that's not what I asked for :)
> Although I will need that in the future as we build on mac and linux
>
> 3. Add some form of a compiler comment - this does not seem to be
> available.
>
> So sorry for the controversy, my solution is simply to add it to the
> project settings. And when we take our project to mac and linux I'll
> have to figure out then what to do with gcc
Hi Peter:
Strangely enough, I just an hour ago discovered that I had forgotten to
send my original response to you. Since you did not seem to be
responding, I just discarded it.
As perhaps the instigator of the controversy, I hesitate to answer
again, but basically I do not understand. If your first header file is
found, and internally your .lib project uses relative addressing (as
indicated by your original post), why are the other headers not found also?
There must be something I am missing here.
Tom Serface
Tom
"Peter Carlson" <peter@h_o_w_u_d_o_d_a_t.com> wrote in message
news:eYylWvQu...@TK2MSFTNGP06.phx.gbl...
Jeff…Relf
" #define Quote_It( It ) #It
C:\\Program Files\\Microsoft DirectX SDK (December 2005)\\__X ) "
in my .CPP file to remind myself that, yeah, it's that SDK.
If someone wants to compile one of my .CPP files ( as has happened )
they can't help but notice: " Yeah, it's that SDK ".
Some of my professonal code was forked by a string of MicroSofties
making 50 dollars an hour on the side... it took them 3 years !
JianJun " Jeff II " Zhu and his ex-MicroSoftie boss ( retired rich )
now control it. They didn't implement all of it,
so I might merge what they did with want I've done.
Jeff…Relf
Like Peter, I had no idea that option even existed.
I much prefer my method, but Peter didn't even mention it.
Tom Serface
the years and often had others in the community come up with different or
better ideas that were ultimately used. It's nothing personal. In fact, I
can't tell you how many times I've learned something new through the
process. I often get more out of these discussions than I put into them.
Tom
"Jeff…Relf" <Jeff...@Yahoo.COM> wrote in message
news:Jeff_Relf_2007_...@Cotse.NET...
Tom Serface
something similar. You may do this as well. I tend to over comment
anything that might be even a little difficult to figure out. I used to do
it for others that might compile the code, but these days I add comments to
myself so I can remember why I did something particular in the code. There
are times when I come back, scratch my head, and say "I did that?" sometimes
proud, sometimes not so proud.
Tom
"Jeff…Relf" <Jeff...@Yahoo.COM> wrote in message
news:Jeff_Relf_2007_...@Cotse.NET...
Peter Carlson
responding correctly.
Jeff...I am unable to use your method. It wont work. Either the full
path, or the macro'd version of a full path. Here's why, and perhaps
the explanation will make things clearer for David.
we use the speex library. It is a cross-platform cross compiler
library. I dont want to modify any of the speex files as this creates a
problem when they release a patch.
To include the speex library, one must #include <path to
speex/include/speex/speex.h>. This works fine either with a relative
path or absolute path. And a pragma comment for the lib works fine as well.
The problem is in speex.h which has several #includes
#include <speex/speex_bits.h> When you build the speex library the
solution finds that paths just fine as they are part of the solution.
However when you build a project dependent on speex it fails.
myproject: #include<...../speex/speex.h> is fine
speex.h: #include<speex/speex_bits.h> <<< fails because there is no
path to it, however this include is inside a 3rd party library.
So putting a Full path in my file wont change the outcome. Only 2
things can help:
1. Alter speex.h to include the path
2. Alter the compiler to include the path
I hope this clears things up.
Peter
David Wilkinson wrote:
>
> As perhaps the instigator of the controversy, I hesitate to answer
> again, but basically I do not understand. If your first header file is
> found, and internally your .lib project uses relative addressing (as
> indicated by your original post), why are the other headers not found also?
>
> There must be something I am missing here.
>
David Wilkinson
> myproject: #include <...../speex/speex.h> is fine
> speex.h: #include <speex/speex_bits.h> <<< fails because there is no
> path to it, however this include is inside a 3rd party library.
Peter:
This is different from what you wrote before
> #include "speex/speex_bits.h" which is relative to the include folder
This is why I always use the "" form of the include, with correct
relative addressing, rather than the <> form (except for standard
library files). Then my files can always be dropped into any project,
and all internal #include's will be handled correctly.
Your problem would also not occur if the author of the library had not
#included other headers in the main header. Was this really necessary?
Chris Becke
the path to the base of the library it to your IDEs include folders search
list OR or the project specific "additional includes".
I work with a Subversion based system, where we have the "current" copy of a
library built into our current-version branch. That way, we can patch up 3rd
party libraries, and the correct version of the patch is fetched along with
our software when we request a particular revision or tag.
Because - with subversion - we have a multi member dev team - each with
their own ideas & requirements of where stuff is fetched to to work on, we
use a relative path for our projects additional include.
So, our directory structure looks something like this :-
c:\my personalwork path\Work\CurrentVersion\ <- contains our workspace and
a subfolder for each sub-project.
c:\my personalwork path\Work\CurrentVersion\OurProject <- our main project
c:\my personalwork path\Work\CurrentVersion\Speex <- A 3rd party library.
Now, with that structure in place, because "c:\my personal work parth" is
different for each developer, AND because we sometimes are required to
parallel develop on CurrentVersion and in Branches, we set the following
path in "OurProject"'s additional includes: "..\speex\include". Because the
additional includes are *always* interpreted relative to the location of the
project (.dsp) file, no matter how convoluted the path to an OurProject
file, a '#include <speex.h>' always resolves correctly.
The moment you use version control to scale a project past a single version
or developer, the projects additional includes setting is the *only* way to
ensure that you can do a checkout of your source on any PC and build it with
no hassles.
Jeff…Relf
" speex.h: #include<speex/speex_bits.h> <<< fails because
there is no path to it, however this include
Unless you're constantly downloading speex patches,
a " Find in Files " search and replace on " <speex/ ",
to give it the full path wouldn't be a lot of work.
Jeff…Relf
#define Quote_It( It ) #It
#define DD_Path( __X ) Quote_It( \
C:\\Program Files\\Microsoft DirectX SDK (December 2005)\\__X )
Tom Serface
"Jeff…Relf" <Jeff...@Yahoo.COM> wrote in message
news:Jeff_Relf_2007_...@Cotse.NET...