bring back setgcc in PM

[kallisti5]

setgcc was a great way to adjust your compiler in the non-PM branches.

The new PM builds use an odd naming convention for gcc:

gcc2h----- gcc - gcc 2 gcc_x86 - gcc 4

gcc4h----- gcc - gcc 4 gcc_x86_gcc2 - gcc 2

This is going to cause a lot of confusion long term..

[zooey]

Replying to kallisti5:

setgcc was a great way to adjust your compiler in the non-PM branches.

Well, it was a rather crude way to adjust the compiler, it has never been great, really: it changed on disk structures to switch the compiler, which means that you couldn't use setgcc in one shell while already having a build running in another.

On PM-Haiku, you should be able to activate a specific compiler by adding its path to the 'PATH' environment variable. This could be done by a script named 'setgcc', of course ... patches welcome ;-)

The new PM builds use an odd naming convention for gcc: gcc2h----- gcc - gcc 2 gcc_x86 - gcc 4

gcc4h----- gcc - gcc 4 gcc_x86_gcc2 - gcc 2

Hm, what's add about that? The primary compiler uses the short name and any secondary compiler is suffixed by its target Haiku architecture. What other naming scheme do you suggest?

[kallisti5]

On PM-Haiku, you should be able to activate a specific compiler by adding its path to the 'PATH' environment variable. This could be done by a script named 'setgcc', of course ... patches welcome ;-)

Indeed, I have no issues with that. It is the proper way to do things (and provide a nice benifit of a "complete" build system)

gcc2h----- alias / symlink gcc = gcc2_x86 gcc2_x86 - gcc 2 gcc4_x86 - gcc 4

gcc4h----- alias / symlink gcc = gcc4_x86 gcc2_x86 - gcc 2 gcc4_x86 - gcc 4

That way things are at least consistant across the platforms. Then setgcc is used to adjust the CC and CXX.

setgcc then would:

update CC and CXX to point to the proper compiler executable

[kallisti5]

setgcc could also check to see if a gcc package is installed and warn the user if it isn't

[kallisti5]

or, using the current naming scheme...

gcc2h----- alias / symlink gcc = gcc_x86_gcc2 gcc_x86_gcc2 - gcc 2 gcc_x86 - gcc 4

gcc4h----- alias / symlink gcc = gcc_x86 gcc_x86 - gcc 4 gcc_x86_gcc2 - gcc 2

[kallisti5]

well.. setgcc still wouldn't work like it did as we can't export the vars out of the script. We would have to instruct users to ". setcc" or echo out the environment and "eval setcc"

[axeld]

Furthermore, you could not simply use 'gcc' anymore to directly address the native compiler. setgcc was a flaw, not a feature :-)

I actually see no use of switching compilers this way. This is stuff that belongs to the build system.

[kallisti5]

fair enough.

Could we at least rename the compilers as per above to add some consistency? (gcc, g++, ld being an alias / symlink to each respective compiler vs having the gcc binary being different things on different platforms.

[axeld]

In my opinion something like this should definitely be done. Even if for the sole reason that I don't have to change my build setup when switching platforms; ie. it should be possible for software to select the default compiler (ie. gcc which will be architecture dependent), always use gcc4, or always use gcc2.

I wouldn't mind in which direction the symlink will point :-)

[bonefish]

Replying to axeld:

[...] ie. it should be possible for software to select the default compiler (ie. gcc which will be architecture dependent), always use gcc4, or always use gcc2.

Did you miss not being able to do that on Haiku? I didn't. If anybody wants to add extra symlinks, feel free to update the recipes and rebuild the primary gcc packages. Please stick to the already used naming convention, though, i.e. "gcc-<arch>", where <arch> is the name of the packaging architecture (i.e. "x86" for x86 gcc 4, "x86_gcc2" for x86 gcc 2, and "x86_64" for x86-64).

Regarding setgcc, that's somewhere on my TODO list, though not top priority (hint!). Given that using the CC and CXX environment variables is a relatively common, but not ubiquitous convention, I would rather use the method Oliver suggested, i.e. adjust PATH. Consequently I would probably name the beast setarch. Obviously it either has to be a shell function or start a new shell. In the latter case it would behave similar to linux32, i.e. could be exit'ed.

[kallisti5]

Ah, making it a shell function is a good idea. Since we have tight control of the Haiku environment, adding little perks like setarch is a nice touch (and makes documentation easier)

[bonefish]

Solved with the introduction of setarch and getarch.