Remove export override directives

[Courtney3141]

This PR removes all export override directives from our makefiles, as discussed here #337.

It was found that export override is not syntactically correct in older versions of GNU make, which happen to be the default for MacOS. Also, the variables which it was being applied to were mandatory environment or command line variables, therefore the export had no effect.

This PR also removes a handful of export directives which were not necessary (on variables which were not used in submakes).

[Courtney3141]

Looks okay to me, maybe we should wait for Peter before merging?

Sure, as long as he has time as I waited a month for him to read the issue and he never got back to me, which is why I asked you.

[wom-bat]

There's a difference between CC=gcc make and make CC=gcc

The first puts CC into the environment; the second puts it into the command line.

The order make takes variables are: inside the makefiles environment commandline

with each overriding the previous one. You need override to make variables set inside the makefile take effect if the same variable names appear in environment or commandline. export adds them to the environment.

When invoking a recursive make with ${MAKE} the same command line variables as were passed to the parent get passed down, even if you've overridden them internally.

[alwin-joshy]

with each overriding the previous one. You need override to make variables set inside the makefile take effect if the same variable names appear in environment or commandline. export adds them to the environment.

But if you're dealing with somethign that is passed in command line arguments, doing an export override has no effect for the submake, right? The only thing you can do is supply a diffferent commandline argument to the submake.

With this being the case and certain versions of make not supporting the composite export override operation, wouldn't we better off getting rid of it? That's what this PR is doing.

[Courtney3141]

with each overriding the previous one. You need override to make variables set inside the makefile take effect if the same variable names appear in environment or commandline. export adds them to the environment.

But if you're dealing with somethign that is passed in command line arguments, doing an export override has no effect for the submake, right? The only thing you can do is supply a diffferent commandline argument to the submake.

With this being the case and certain versions of make not supporting the composite export override operation, wouldn't we better off getting rid of it? That's what this PR is doing.

I think the issue with re-defining BUILD_DIR is not necessarily just about submake, it's about when BUILD_DIR is being passed to MAKE inside the makefile.

The additional override directives I added indeed have no effect on the value of BUILD_DIR inside submakes if BUILD_DIR is passed as a command line arg, but that doesn't seem to be a problem?

[Courtney3141]

But I do split up all export override directives onto two lines which is defined.