Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.sys.acorn.programmer > #5705 > unrolled thread

GCC4 directory/extension names

Started bydruck <news@druck.org.uk>
First post2019-03-06 13:14 +0000
Last post2019-03-11 15:44 +0000
Articles 7 — 3 participants

Back to article view | Back to comp.sys.acorn.programmer


Contents

  GCC4 directory/extension names druck <news@druck.org.uk> - 2019-03-06 13:14 +0000
    Re: GCC4 directory/extension names Theo <theom+news@chiark.greenend.org.uk> - 2019-03-06 16:09 +0000
      Re: GCC4 directory/extension names druck <news@druck.org.uk> - 2019-03-10 19:16 +0000
        Re: GCC4 directory/extension names Theo <theom+news@chiark.greenend.org.uk> - 2019-03-10 21:10 +0000
          Re: GCC4 directory/extension names Ronald <gettingchoppy@gmail.com> - 2019-03-11 11:45 +1300
            Re: GCC4 directory/extension names druck <news@druck.org.uk> - 2019-03-11 20:42 +0000
          Re: GCC4 directory/extension names druck <news@druck.org.uk> - 2019-03-11 15:44 +0000

#5705 — GCC4 directory/extension names

Fromdruck <news@druck.org.uk>
Date2019-03-06 13:14 +0000
SubjectGCC4 directory/extension names
Message-ID<q5oh39$1h7$1@dont-email.me>
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

[toc] | [next] | [standalone]


#5707

FromTheo <theom+news@chiark.greenend.org.uk>
Date2019-03-06 16:09 +0000
Message-ID<27o*PW-hx@news.chiark.greenend.org.uk>
In reply to#5705
druck <news@druck.org.uk> wrote:
> 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

[toc] | [prev] | [next] | [standalone]


#5712

Fromdruck <news@druck.org.uk>
Date2019-03-10 19:16 +0000
Message-ID<3feab39257.druck@druck.org.uk>
In reply to#5707
On 6 Mar 2019 Theo <theom+news@chiark.greenend.org.uk> wrote:
> druck <news@druck.org.uk> wrote:
>> 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/

[toc] | [prev] | [next] | [standalone]


#5713

FromTheo <theom+news@chiark.greenend.org.uk>
Date2019-03-10 21:10 +0000
Message-ID<U+y*u9vix@news.chiark.greenend.org.uk>
In reply to#5712
druck <news@druck.org.uk> wrote:
> 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

[toc] | [prev] | [next] | [standalone]


#5714

FromRonald <gettingchoppy@gmail.com>
Date2019-03-11 11:45 +1300
Message-ID<6b13c79257.beeb@-.->
In reply to#5713
In message <U+y*u9vix@news.chiark.greenend.org.uk>
          Theo <theom+news@chiark.greenend.org.uk> wrote:

> druck <news@druck.org.uk> wrote:
> > 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

[toc] | [prev] | [next] | [standalone]


#5716

Fromdruck <news@druck.org.uk>
Date2019-03-11 20:42 +0000
Message-ID<q66h8d$8ig$1@dont-email.me>
In reply to#5714
On 10/03/2019 22:45, Ronald wrote:

[Getting GCC4 to recognise #include "file.hpp"]

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

> 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

[toc] | [prev] | [next] | [standalone]


#5715

Fromdruck <news@druck.org.uk>
Date2019-03-11 15:44 +0000
Message-ID<q65vo7$gcf$1@dont-email.me>
In reply to#5713
On 10/03/2019 21:10, Theo wrote:
> druck <news@druck.org.uk> wrote:
>> 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

[toc] | [prev] | [standalone]


Back to top | Article view | comp.sys.acorn.programmer


csiph-web