dynpmc/Makefile problem on Solaris 8/SPARC at r39040

[doughera]

While trying to test another patch today (r39040), I ran into this problem on Solaris 8/SPARC, building with gcc-4.1.0:

(This is while trying to compile src/dynpmc/dynlexpad.c. I have removed all the irrelevant flags to clarify what's happening.)

gcc -c -odynlexpad.o [-flags] dynlexpad.c
/usr/ccs/bin/as: error: no input filename given
usage: /usr/ccs/bin/as [-V] [-Q{y,n}] [-f[O][if]#] [-q] [-s]
          [-S] [-K {pic,PIC}] [-o objfile] [-L] [-T]
          [-P [[-Ipath] [-Dname] [-Dname=def] [-Uname]]...]
          [-m [-Ym,path]] [-n] [-ul] [-xF] [-xarch=v7] [-xarch=v8] [-xarch=v8a] [-xarch=v8plus] [-xarch=v8plusa] [-xarch=v8plusb]  [-xarch=v9] [-xarch=v9a] [-xarch=v9b]  [-xcode={pic13,pic32}] file.s...
*** Error code 1
make: Fatal error: Command failed for target `dynlexpad.o'
Current working directory /home/doughera/src/parrot/parrot-gcc/src/dynpmc
*** Error code 1
make: Fatal error: Command failed for target `dynpmc.dummy'

The problem is the '-odynlexpad.o'. The assembler is expecting a space after the -o option. There used to be one. Something has changed recently

[doughera]

The attached patch fixes this problem. On the surface, the problem is that the CC_OUT Makefile macro contained a space, but 'make' isn't good at preserving trailing spaces in variable expansions. A second, minor problem is that the Makefile redefined CC to be 'cc -c'. It's rarely a good idea to redefine a standard Makefile variable to be something different. For example, this redefinition made it impossible to do something like

    make CC=gcc-4.3

while in the root directory.

Somewhat more deeply, this patch continues on the trail I was following in TT #698 of trying to move conditional stuff out of Makefile generation up into the Configure.pl level. Parrot has a mish-mash of conditional stuff, especially related to installation and to win32- and cygwin-specific behavior. Some is done in Configure.pl. Some is done at Makefile generation time. Some is done while building things like parrot_config. Some is done while building and running pbc_to_exe. Sometimes it's redundant. Sometimes it's self-contradictory. Sometimes it's clumsy. Overall, I find it very confusing. I think the patches in TT #698 and here are heading in the right direction to simplify things a little.

[allison]

Thanks, applied in r40130.