Discussion:
GCC4 directory/extension names
(too old to reply)
druck
2019-03-06 13:14:16 UTC
Permalink
Hi,

Anyone know a definitive list of what GCC4 g++ supports for the names of
directories corresponding to the file extensions of sources and headers
on other platforms?

It seems to be happy with the source files in c, cc, cpp or c++
directories, but it seems that header files can only be in a h or hh
directory. Attempting to include hpp or h++ extensions fail.

That's causing a bit of a problem when dealing with cross platform
stuff. Along with not running from an amu makefile, and taking hours to
compile...

---druck
Theo
2019-03-06 16:09:10 UTC
Permalink
Post by druck
Hi,
Anyone know a definitive list of what GCC4 g++ supports for the names of
directories corresponding to the file extensions of sources and headers
on other platforms?
Look at the *sfix system variables. I can't remember the exact names
without looking them up, but it's something like gcc$env$sfix.
I think the !Run sets the default values.

There's more about this in !GCC.!Help.

Theo
druck
2019-03-10 19:16:31 UTC
Permalink
Post by Theo
Post by druck
Anyone know a definitive list of what GCC4 g++ supports for the names of
directories corresponding to the file extensions of sources and headers
on other platforms?
Look at the *sfix system variables. I can't remember the exact names
without looking them up, but it's something like gcc$env$sfix.
I think the !Run sets the default values.
There's more about this in !GCC.!Help.
It's buried down in !GCC.Docs.libunixlib.README, and set in the !GCC.!Run
file. So I added hpp, hxx, and h++ to the variable:-

Set UnixEnv$gcc$sfix
"f:for:F:fpp:cc:cxx:cpp:c++:C:i:ii:rpo:c:m:h:hh:hxx:hpp:h++:s:S:xrb:xrs:l:o:y:tc
c:cmhg:adb:ads:ali"

(Further down UnixEnv$g++$sfix is set from UnixEnv$gcc$sfix)

But that didn't work, it still didn't recognise #include "something.hpp"
I tried gcc$env$sfix to, but looking in !SharedLibs.libs.libunixlib
"UnixEnv$appname$sfix" is the correct variable name.

Tried reducing it down to just
Set UnixEnv$g++$sfix c:cpp:h:hpp

fatal error: something.hpp: No such file or directory

No luck again :-(

---druck
--
The ARM Club Free Software - http://www.armclub.org.uk/free/
32 bit Conversions Page - http://www.armclub.org.uk/32bit/
Theo
2019-03-10 21:10:42 UTC
Permalink
Post by druck
But that didn't work, it still didn't recognise #include "something.hpp"
I tried gcc$env$sfix to, but looking in !SharedLibs.libs.libunixlib
"UnixEnv$appname$sfix" is the correct variable name.
Since it's the preprocessor reading the header files, you might need to set
UnixEnv$cpp$sfix - I don't know if that's set by the !Run file?

Theo
Ronald
2019-03-10 22:45:49 UTC
Permalink
Post by Theo
Post by druck
But that didn't work, it still didn't recognise #include "something.hpp"
I tried gcc$env$sfix to, but looking in !SharedLibs.libs.libunixlib
"UnixEnv$appname$sfix" is the correct variable name.
Since it's the preprocessor reading the header files, you might need to set
UnixEnv$cpp$sfix - I don't know if that's set by the !Run file?
Theo
I thought gcc was the frontend for everything it does thereafter.
I recall making UnixEnv$ changes sometimes required a reboot to get
the true result.
There is a build file for gcc with the riscosify list, I think it
was to do with libscl though.

You may also get through it with the ? wild card as long as there is no
similar .h files.

Lastly, I have a !GCC built without riscosification so norcroft source
code has to be flattened to resemble linux files, or standard source
files just work.
That usually fixes any naming problems. I could upload it to my
GoogleDrive I guess.

Ronald
druck
2019-03-11 20:42:51 UTC
Permalink
On 10/03/2019 22:45, Ronald wrote:

[Getting GCC4 to recognise #include "file.hpp"]
Post by Ronald
You may also get through it with the ? wild card as long as there is no
similar .h files.
Much strangeness tonight. I had a good play with setting wildcards, but
didn't have any luck. I noticed that the g++ command I was using was of
the form "g++ <opts> cpp.file", as it had come from a makefile processed
by amu (the project was formerly using Acorn C++, but went off to Linux
and came back needing c++11 and hence g++), so I used gnu make instead
which generated a command with "g++ <opts> file.cpp" - this managed to
find the .hpp and compiled. Even more strangely, the original cpp.file
command line then worked. It was ok with both a simplified sfix, and the
full version I put in a previous post.

I'll have to do a reboot, and see the exact sequence of actions which
caused it to start working. But at least its going now, thanks for
everyone's help.
Post by Ronald
Lastly, I have a !GCC built without riscosification so norcroft source
code has to be flattened to resemble linux files, or standard source
files just work.
That usually fixes any naming problems. I could upload it to my
GoogleDrive I guess.
That would be useful, as I have to mess around with scripts to unflatten
the files when copying them from a where they've been checked out on a
shared drive to RISC OS, and flatten and copy then back again after.

---druck

druck
2019-03-11 15:44:06 UTC
Permalink
Post by Theo
Post by druck
But that didn't work, it still didn't recognise #include "something.hpp"
I tried gcc$env$sfix to, but looking in !SharedLibs.libs.libunixlib
"UnixEnv$appname$sfix" is the correct variable name.
Since it's the preprocessor reading the header files, you might need to set
UnixEnv$cpp$sfix - I don't know if that's set by the !Run file?
Yes, the variables for all the other gcc programs are copied from the
gcc one, so cpp also has the new prefixes.

---druck
Loading...