0

I'm trying to get a custom compiler working in CLion and having a bear of a time. Can anyone help me find out what I'm doing wrong? I have the full code on Github.

What I have

  • The command line tools are all behind the same executable named mpw. So the C compiler is behind mpw SC, the linker is behind mpw link. There's also a tool named Rez to add some metadata to the executable, but I'm fine if CLion just ignores that.
  • I'm using a make file to do the actual build.
  • I've created a custom compiler definition YAML and selected it in CLion's project settings. I tried to follow the Jetbrains docs [1] [2] but couldn't find out what code insight target name to use (It eventually compiles for 68000 CPU, old MacOS, anyone know where I can find a list of allowed clangd target names?).
  • The Makefile works when I call make clean or make all from command line.

Problem

When I open the folder in CLion, it tries to parse the Makefile and reports:

(x) Analysing makefile
(x) No compilation commands found

Goal

  • Get CLion to see all my code (including system headers at ~/mpw/Interfaces/CIncludes) so I can use its code navigation to auto-complete code. Refactoring would be nice too.
  • Get CLion to understand my Makefile so I can build using the "hammer" icon inside CLion.

Custom Compiler Definition


compilers:
  - description: "MPW SC"
    match-sources: ".*\\.c"
    match-language: "C"
    match-compiler-exe: "(.*/)?mpw SC"
    code-insight-target-name: mpw
    include-dirs:
      - ${user-home}/mpw/Interfaces/CIncludes
    defines-text: "
#define __MRC__ 0x0700
#define OLDROUTINENAMES 1
"

Makefile

SOURCES=SillyBalls.c
RFILES=SillyBalls.r Size.r
EXECUTABLE=SillyBalls

MPW=~/Programming/mpw/build/bin/mpw
RINCLUDES=~/mpw/Interfaces/RIncludes

LDFLAGS =-w -c 'SILB' -t APPL \
    -sn STDIO=Main -sn INTENV=Main -sn %A5Init=Main

LIBRARIES={Libraries}Stubs.o \
    {Libraries}MacRuntime.o \
    {Libraries}IntEnv.o \
    {Libraries}Interface.o \
    {Libraries}ToolLibs.o \
    {CLibraries}StdCLib.o

TOOLBOXFLAGS=-d OLDROUTINENAMES=1 -typecheck relaxed

OBJECTS=$(SOURCES:%.c=obj/%.o)

all: prepass bin/$(EXECUTABLE)

prepass:
    mkdir -p obj bin

bin/$(EXECUTABLE): $(OBJECTS)
    $(MPW) link $(LDFLAGS) $(OBJECTS) $(LIBRARIES) -o $@
    Rez -rd $(RFILES) -o $@ -i $(RINCLUDES) -append

obj/%.o : %.c
    $(MPW) SC $(TOOLBOXFLAGS) $< -o $@

clean:
    rm -rf bin obj
uliwitness
  • 8,532
  • 36
  • 58
  • What's all that `{Libraries}` and `{CLibraries}` stuff? Do you really have files with those literal names? You don't appear to be building those, so do those names have special meaning to `mpw`, or something? – John Bollinger Oct 06 '22 at 18:26
  • 1
    It may be that CLion is not smart enough to recognize that the expansion of (say) `$(MPW) SC` matches your C compiler pattern. You could try instead defining and using `CC = ~/Programming/mpw/build/bin/mpw SC`, *etc*.. – John Bollinger Oct 06 '22 at 18:31
  • Yeah, `{Libraries}` etc. are standard symbols for some standard folders the compiler knows how to find. – uliwitness Oct 06 '22 at 19:47
  • Thanks, that seems to be part of the problem: I added `CC="~/Programming/mpw/build/bin/mpw SC"` and `LD="~/Programming/mpw/build/bin/mpw link"` it seems more happy, though it of course now says `Cannot find compiler executable: '~/Programming/mpw/build/bin/mpw SC'` which is true. Maybe I can create a bash script that forwards to these two sub-commands. – uliwitness Oct 06 '22 at 19:56

1 Answers1

0

Thanks to @JohnBollinger for getting me on the right track:

CLion is apparently not smart enough to recognize $(MPW) SC as mpw SC. If I change it to

CC="~/Programming/mpw/build/bin/mpw SC"

CLion is happy, but of course there is no file named mpw SC.

So my solution was to create a shell script sc.sh:

#!/bin/zsh

~/Programming/mpw/build/bin/mpw SC $@

and then set

CC=./sc.sh

and

  match-compiler-exe: "(.*/)?sc.sh"

and then use ./sc.sh everywhere where I used to have $(MPW) SC

CLion recognizes it, starts indexing the system headers, and the "hammer" icon triggers a build all just as desired.

uliwitness
  • 8,532
  • 36
  • 58
  • 1
    Or you could just lose the quotes in your variable definitions. They are neither necessary for nor meaningful to `make`, but when `make` carries them forward to the shell, the problem you describe arises. It was not accidental that I omitted quotes from my suggestion in comments on the question. – John Bollinger Oct 06 '22 at 20:38
  • You're right, if I do a binary directory path instead of the path *including* the mpw tool, it will be recognized even if it's a separate variable. Updating the answer accordingly. – uliwitness Oct 08 '22 at 16:44
  • Dangit, I just realized it does _not_ work. It must have cached something making it seem like that worked. The script is necessary after all. – uliwitness Oct 10 '22 at 19:01