g++ with absolut path for errors / warnings

[Philipp Kraus]

Hello,

I use a Scons script for compiling my sources with g++. Can I set a
command line flag of g++ to see the full path on warning or error
messages? I use relative paths for compiling the source, but I need
messages with a absolute path.

Thanks a lot

Phil

 

[Jorgen Grahn]

Hello,

I use a Scons script for compiling my sources with g++. Can I set a
command line flag of g++ to see the full path on warning or error
messages? I use relative paths for compiling the source, but I need
messages with a absolute path.

If it's not document in the exhaustive reference manual, then most
likely "no". It's not something people generally need.

/Jorgen

 

[Joshua Maurice]

Hello,

I use a Scons script for compiling my sources with g++. Can I set a
command line flag of g++ to see the full path on warning or error
messages? I use relative paths for compiling the source, but I need
messages with a absolute path.

Not really C++ related, but IIRC g++ will output warnings and errors
with absolute paths if you give it absolute paths. I know you just
said that you work in terms of relative paths, but does Scons have a
function to convert a path to an absolute path which you could call on
all of the paths right before you give it to g++?

 

[Jorgen Grahn]

Not really C++ related, but IIRC g++ will output warnings and errors
with absolute paths if you give it absolute paths.

It almost certainly does -- trying to find a name for and trim the
current working directory would be a lot of effort, with uncertain
outcome, and would be surprising from a user interface perspective.

Still, his need for the absolute path smells like a design error --
one that will come back and haunt him later even if he solves this
one. It reminds me a bit of Windows-based build setups I've seen,
where you couldn't build unless you arranged your DOS drive letters in
a very specific way :-/

/Jorgen

 

[Philipp Kraus]

Not really C++ related, but IIRC g++ will output warnings and errors
with absolute paths if you give it absolute paths. I know you just
said that you work in terms of relative paths, but does Scons have a
function to convert a path to an absolute path which you could call on
all of the paths right before you give it to g++?

I compile my code via external targets under XCode 3.2 and would like
to get the errors within the source code. On XCode Version changing <
3.2 to 3.2 it seems, that the inline errors are shown always if the
compiler returns errors with absolut path names. I have tried now to
change the input path names to absolut pathes, but it doesn't work,
because the include within the sources are relative. The source will be
compiled but all errors are with relative path names and so XCode can't
parse them for inline showing.

Phil

 

[Ian Collins]

I compile my code via external targets under XCode 3.2 and would like to
get the errors within the source code.

You should really be asking this on a tool specific list, it isn't a C++
language issue.

 

[Philipp Kraus]

You should really be asking this on a tool specific list, it isn't a
C++ language issue.

I have hopen that anyone has the same problems. On the Apple
mailinglist the problem can be found
http://discussions.apple.com/message.jspa?messageID=10439497 but the
the hint with absolut pathes does not work. I have template classes and
a lot of "inline" declaration. I pass absolute pathes to gcc, but the
returning error messages relative pathes. I think because the includes
in the file are relative.

Thanks a lot

Phil

 

[Miles Bader]

I have hopen that anyone has the same problems. On the Apple
mailinglist the problem can be found
http://discussions.apple.com/message.jspa?messageID=10439497 but the
the hint with absolut pathes does not work. I have template classes
and a lot of "inline" declaration. I pass absolute pathes to gcc, but
the returning error messages relative pathes. I think because the
includes in the file are relative.

Can you just pass the compiler / make output through a simple text
filter that makes relative pathnames absolute?

E.g., instead of running "make", you coudl run "make 1>&2 | my_filter",
and my_filter would prepend the current directory to any relative
filenames in error messages it sees.

-Miles

 

[Joshua Maurice]

I have hopen that anyone has the same problems. On the Apple
mailinglist the problem can be foundhttp://discussions.apple.com/message.jspa?messageID=10439497but the
the hint with absolut pathes does not work. I have template classes and
a lot of "inline" declaration. I pass absolute pathes to gcc, but the
returning error messages relative pathes. I think because the includes
in the file are relative.

Sure you passed all of the paths as absolute paths, including the
include paths as absolute paths? Was the error message in a standard
header or in a header which was found from an explicit include path
command line option? Just curious.

 

[Philipp Kraus]

Sure you passed all of the paths as absolute paths, including the
include paths as absolute paths?

I can't use absolute path names, because the source files are
cross-plattform within a subversion. On a MS system I need a drive
letter on unix system I have only directories. Scons can create on a
file the correct absolut path with drive letter on MS and leading slash
on unix systems, but Scons call the compiler only for the cpp files,
not for my hpps.

Was the error message in a standard
header or in a header which was found from an explicit include path
command line option? Just curious.

No, my code works, but I insert in my hpps an error to test the message
bubbles of XCode. So XCode runs the external target, that calls Scons
(works like makefiles) and should be insert the compiler error message
on that position where I have inserted the error.

My main program has a include with "#include <myheader.hpp>", so the
Scons script create a main.o but the #include has an relative path, so
an error is shown also as relative path and XCode does not parse this.

I have posted a message on the Apple mailinglist and hope that somebody
can help me. I can do my work, but it's not a good solution.

Phil

 

[Öö Tiib]

I can't use absolute path names, because the source files are
cross-plattform within a subversion. On a MS system I need a drive
letter on unix system I have only directories. Scons can create on a
file the correct absolut path with drive letter on MS and leading slash
on unix systems, but Scons call the compiler only for the cpp files,
not for my hpps.


No, my code works, but I insert in my hpps an error to test the message
bubbles of XCode. So XCode runs the external target, that calls Scons
(works like makefiles) and should be insert the compiler error message
on that position where I have inserted the error.

My main program has a include with "#include <myheader.hpp>", so the
Scons script create a main.o but the #include has an relative path, so
an error is shown also as relative path and XCode does not parse this.

I have posted a message on the Apple mailinglist and hope that somebody
can help me. I can do my work, but it's not a good solution.

I have had similar problem using VS as IDE to cross-compile for an
embedded system. When you double click in VS onto error or warning
message it opens the file at described position; that is handy. It
assumes specific pattern that MSVC outputs as error or warning
messages. That pattern assumed absolute path to file but compiler for
that embedded device did output relative paths.

Solution was quite simple perl script that was made to be called by
makefile to postprocess the compiler output and translate the error
messages into edible for VS. It is quite likely that you can do
something similar with that XCode of yours.

 

[Jorgen Grahn]

.

I compile my code via external targets under XCode 3.2 and would like
to get the errors within the source code. On XCode Version changing <
3.2 to 3.2 it seems, that the inline errors are shown always if the
compiler returns errors with absolut path names.

I suggest you report the bug in XCode, and switch to some other tool
if it's not fixed and you need it to work. All other editors work
fine with g++, so I doubt the GCC people will compensate for someone
else's bug.

A workaround or glue layer from your side seems error-prone and ugly.

/Jorgen