Retro68 IDEs: Visual Studio Code, Eclipse, CodeLite, ...

[Frobozz]

I'm trying to get a good cross-compile environment set up to write 68K Mac apps from my modern Mac (OS: Big Sur). I've tried 3 IDEs so far, with mixed, but distinct results. Curious about others using Retro68, and their experiences. Hopefully this will be helpful to me, and also anyone coming along with the same questions. 

Retro68: https://github.com/autc04/Retro68

CodeLite

I hadn't used CodeLite before. It's a cross-platform IDE with C/C++ support. It's fairly zippy, not Java, but doesn't use native OS X controls, so some things like cut/paste need right-clicks. 

References:

• http://www.toughdev.com/content/2018/12/developing-68k-mac-apps-with-codelite-ide-retro68-and-pce-macplus-emulator/
  
• http://www.toughdev.com/content/2017/03/exploring-retro68-gcc-based-sdk-for-68k-macintoshes/
  

Experience:

• Thanks to ToughDev's pages above, it wasn't super hard to get this compiling. I configured LaunchAPPL to use Mini vMac, and that's just fantastic.
  
• hello world and "dialog" (sample program from Retro68) compile no problem.
  
• BUT... A good chunk of the 68K headers, if I use them, will fail to load, and I won't be able to compile.
  
  
  For example, "Quickdraw.h". I'm using the universal headers, from MPW, I think version 3.4 of the headers. For example, <Controls.h> will say it's not found. But the file is there, so that's just a wonky error message. If I open Controls.h in CodeLite, I can see a more specific error, where the include for <MacTypes.h> is: "In included file: 'stdbool.h' file not found. /Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/stdbool.h:28:15
  
  
  stdbool.h is not directly linked there, but something is pulling it in. 
  
• the particular version of that file above has an #include_next. Not sure if that's where its failing, or how to fix it. 
  

Eclipse

I have more experience with Eclipse, mostly from doing Amiga cross-compiles. Eclipse is java based, has a few UI quirks, but obviously tons of extensions and configuration. Eclipse doesn't use cmake, as I understand it, but it can apparently read an existing cmake project and create something in it's own way. I haven't tried that yet (see ref). 

Experience:

• I have it compiling by calling cmake via script. (again, not the way it wants to do it, but haven't had time to explore yet). Of the 3, this is the one working "best", but I'm essentially using it as a glorified text editor at this point, and could probably achieve similar results with BBEdit. (plus have better search)
  
• Annoyance: it is spewing up THOUSANDS of warnings from gcc about the 68k Mac includes. They are all the same warning category:
  
  
  /Retro68-build/toolchain/universal/CIncludes/CodeFragments.h:322:1: warning: 'GetSharedLibrary' initialized and declared 'extern'
  
• I googled a bit and tried a couple things to suppress that particular warning, but haven't had any luck to date. It's not the end of the world, but it fills the output when compiling, so hard to find warnings/errors you actually do need to care about. 
  

[*]2nd Annoyance: once you have used cmake script to compile it once, and hit then hit compile again, eclipse gets confused because it's finding main() twice, etc. When I have 5 mins I'll tweak the script to erase the cmake stuff on compile, I'm sure that will take care of it. Only listing it because I suppose there's a possibility it can't be fixed, and the real thing is to I guess convert the project from the cmake project to an Eclipse style one. 





References:

• Retro68 setup: None, but I could put together a write up of how I got it (kind of) working if anyone is interested.
  
• https://jvgomez.github.io/pages/how-to-configure-a-cc-project-with-eclipse-and-cmake.html
  
• gcc warning:
  
  
  https://stackoverflow.com/questions/4268589/warning-in-extern-declaration
  
• https://gcc.gnu.org/onlinedocs/gcc-3.4.6/gcc/Warning-Options.html
  
• https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45977
  

Visual Studio Code

This is a native Mac app, and pretty zippy (even with the x86 version running under Rosetta2). I have never used this before today. 

Experience:

• Frustrating. I've been messing around with the config files, can't can't quite get it to do the right thing. Anybody have this working for Retro68?
  
• It is inserting -arch=x86_64 into the gcc command line, and that causes the gcc version in retro68 to barf. I can't find out where it is doing this, and how to turn it off. 
  
  
  is not able to compile a simple test program.
  [cmake] 
  [cmake]   It fails with the following output:
  [cmake] 
  [cmake]     Change Dir: /Users/micahbly/dev/vsc-workspace-mac68k/HelloWorld/build/CMakeFiles/CMakeTmp
  [cmake]     
  [cmake]     Run Build Command(s):/usr/bin/make cmTC_b2a23/fast && /Library/Developer/CommandLineTools/usr/bin/make  -f CMakeFiles/cmTC_b2a23.dir/build.make CMakeFiles/cmTC_b2a23.dir/build
  [cmake]     Building C object CMakeFiles/cmTC_b2a23.dir/testCCompiler.c.o
  [cmake]     /Users/micahbly/dev/GitHub/Retro68-build/toolchain/bin/m68k-apple-macos-gcc   -arch x86_64 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX11.1.sdk -o CMakeFiles/cmTC_b2a23.dir/testCCompiler.c.o -c /Users/micahbly/dev/vsc-workspace-mac68k/HelloWorld/build/CMakeFiles/CMakeTmp/testCCompiler.c
  [cmake]     m68k-apple-macos-gcc: error: x86_64: No such file or directory
  [cmake]     m68k-apple-macos-gcc: error: unrecognized command line option '-arch'; did you mean '-march='?
   
  

References:

• https://code.visualstudio.com/docs
  
• https://code.visualstudio.com/docs/getstarted/introvideos
  
• https://code.visualstudio.com/docs/cpp/configure-intellisense-crosscompilation
  
• https://code.visualstudio.com/docs/cpp/cmake-linux
  
•  
  

 

[Frobozz]

Well, since I made that comment about BBEdit, I thought I might as well add that configuration as well. It was painless, and I think I like it better at this point. I am going to miss Eclipse catching dumb typos and mistakes for me before I even build, but there's a lot to be said for a fast UI and great search abilities too. 

Here's a little write up of how I configured BBEdit to work with Retro68. 

Setting up Retro68

Retro68 setup is beyond the scope of this post, but after you get it built, you need to configure the LaunchAPPL tool to point to your favorite simulator. I prefer Mini vMac, but it handles a number of simulators (and even serial connections!).

1. Review the LaunchAPPL and the Test Suite section of the Retro68 doc: Retro68-build/toolchain/bin/LaunchAPPL
   
2. “To specify either environment as a default, or to configure one of the other emulators, copy the file Retro68/LaunchAPPL/LaunchAPPL.cfg.example to ~/.LaunchAPPL.cfg and edit to taste (documentation is provided in comments).”
   
3. As an example, here is my config:
   

# emulator = minivmac

    # All minivmac related paths are specified relative to minivmac-dir:
minivmac-dir = /Users/xxx/Documents/Classic_Computers/Mac/Mac_Emulation/MiniVmac/

    # First, we need Mini vMac itself:
# minivmac-path = ./Mini vMac
    # On Macs, specify the path of the application bundle, not the executable inside it:
minivmac-path = ./Mini vMac x64 1280x800 8x LT.app

    # A ROM file:
minivmac-rom = ./vMac.ROM

    # Next, a system disk image (System 6 or earlier)
system-image = ./other_disk_images/Disk608.dmg

    # And finally, autoquit:
autoquit-image = ./mini_vmac_utilities/autoquit-1.1.1.dsk






Setting up BBEdit

Before we set up a test project, we have some one-time setup work to do in BBEdit. We’re going to set up a few scripts to help us build, check, and run the retro68 apps we build. For the most part, you just need to copy the scripts I provided and then adjust paths where necessary. I use cppcheck, but you might not use it, so feel free to skip any references to that below.

1. In BBEdit, select Scripts > Open Scripts Folder. (The scripts menu is an icon that looks like an AppleScript script, but fear not! We will not need to use AppleScript.). The BBEdit scripts folder common to your user will open in the Finder.
   
2. Copy the 4 scripts I provided. You might need to chmod them to make them executable on your machine. You might need to right-click to open them as well the first time, because of the security features in recent OS X versions. Not sure.
   
3. Open retro68_cppcheck.sh in BBEdit.
   
4. Set the path to cppcheck as it exists on your system. (I’m having some M1/homebrew/zsh related weirdness with my new machine, so I hardcoded the full path. You shouldn’t need to do that).
   
5. In that same file, adjust the path to the CIncludes and RIncludes folders in your Retro68-build folder.
   
6. Open retro68_build.sh in BBEdit.
   
7. Set the path to your local copy of Retro68-build/toolchain/m68k-apple-macos/cmake/retro68.toolchain.cmake.
   
8. Open retro68_build_and_run.sh in BBEdit.
   
9. Set the path to your local copy of Retro68-build/toolchain/bin/LaunchAPPL. Ideally, you have this in your path already, but again, I’m just having some weirdness right now and have to hard code it.
   
10. Ok, now your scripts are set up. You don’t need to adjust these again for each project.
    
11. Optionally, assign key shortcuts to some or all of the scripts. The easiest way is to open Window > Palettes > Scripts, click on a script, the click on Set Shortcut. You can also do it through the Preferences UI.
    

Setting up a sample project in BBEdit

1. Create a new project. File > New > Project…
   
   • 
     
     I am using ~/dev/bbedit-workspace-mac68k to hold all my Bbedit 68K apps
     
   • Click New Folder and name it after your project. For this example, I’m going to build the “Dialog” sample from Retro68, so that’s the name I’m using for the folder
     
   • Save the BBEdit project description in that folder. In this case, Dialog.bbprojectd
     
2. Right click in the project window that opens, and select New Text File…. A save dialog will come up.
   
3. Save as “_ProjectName.txt”. This file isn’t part of the Retro68 build, but it will help our build scripts.
   
4. In the first line of the blank file that opens, type “Dialog”, and save. For each project we make, we’ll need a file with this same name, and we’ll need to put the name of the project on the first line. Subsequent lines will be ignored, so you can use them for comments. The main significance of this name is that the resulting Mac binary will be named after it.
   
5. Right click again, and select New Text File… again.
   
6. Save as dialog.c.
   
7. Locate the Retro68/Samples/Dialog folder, find dialog.c, open it and copy/paste the contents into your Bbedit dialog.c file. (Alternatively, you could duplicate the file, move it to your BBEdit project directory, and then drag that into the BBEdit project window to associate it with the project).
   
8. Create another blank text file, and this time populate it with the contents of dialog.r from the sample project. This is the text description of the resource file for the app.
   
9. Create another text file, and save it as CMakeLists.txt.
   
10. Paste the following into the CMakeLists.txt file, and save it. That comples the project.
    

# we don't seem to care, but 2.8.12 and below produces a kind of warning from cmake about 2.8.12 going extinct soon.
cmake_minimum_required(VERSION 2.8.13)

## Use the variable PROJECT_NAME for changing the target name
set( PROJECT_NAME "Dialog" )

## Set our project name
project(${PROJECT_NAME})

## Define the executable
add_application(Dialog
    dialog.c
    dialog.r
   )




Checking the Project with Cppcheck (Optional)

1. If you have cppcheck installed we can now run it and see what it says. If you don’t have cppcheck, or don’t care, you can skip this whole thing.   
   
2. If you assigned a shortcut key to the cppcheck script, hit that key now to run the check. BBEdit will show any results in a console window. If you didn’t assign a shortcut, select “retro68_cppcheck” from the Scripts menu.
   
3. make any fixes you want to make (I get some noise with this particular project, and suspect I’ll need to do some tuning of cppcheck when working with these old Mac headers).
   

Building the Project

Let’s build the project and see if our CMake setup is working.

• If you assigned a shortcut key to the build script, hit that key now to start the build. BBEdit will show any results in a console window. If you didn’t assign a shortcut, select “retro68_build” from the Scripts menu.
  

This is what I get for output:

~/Library/Application Support/BBEdit/Scripts/retro68_build.sh
--------------------------------------------------------------------------------
-- The C compiler identification is GNU 9.1.0
-- The CXX compiler identification is GNU 9.1.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /Users/xxx/dev/GitHub/Retro68-build/toolchain/bin/m68k-apple-macos-gcc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /Users/xxx/dev/GitHub/Retro68-build/toolchain/bin/m68k-apple-macos-g++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/xxx/dev/bbedit-workspace-mac68k/Dialog/build
Scanning dependencies of target Dialog
[ 25%] Building C object CMakeFiles/Dialog.dir/dialog.c.obj
[ 50%] Linking C executable Dialog.code.bin
[ 50%] Built target Dialog
Scanning dependencies of target Dialog_APPL
[ 75%] Generating dialog.r.rsrc.bin
[100%] Generating Dialog.bin, Dialog.APPL, Dialog.dsk, Dialog.ad, %Dialog.ad
[100%] Built target Dialog_APPL




Looks good. If you got any error messages, you’ll want to fix those up before proceeding.

Building and Running

The next script simply calls the build script we just ran, and then tries to launch the built app in an emulator. I set up LaunchAPPL to use Mini vMac. If you configured Sheepshaver or Basilisk II or something else, that will be used instead.

Hit the shortcut or select retro68_build_and_run from the Scripts menu. The app will be built, and then your simulator will start up, and then the app will be executed automatically. Using Mini vMac, after I exit the app in the emulated Mac, the simulator also shuts down automatically.

Cleaning

If you want to clean out the build, I provided a script for that. It only cleans the current project, but you could easily make a variant that cleans all projects if that is helpful.



View attachment retro68_build_and_run.sh
View attachment retro68_build.sh
View attachment retro68_clean.sh
View attachment retro68_cppcheck.sh

 

[Crutch]

This is very interesting, thanks.

I have a question.  Why mess about with retro68 etc. at all?  I do a lot of vintage 68k dev on modern Macs lately ... I do it by just running vintage Symantec C++ 7 in Basilisk II on my MacBook Air.

Is it just that you want to use a modern text editor?  BBEdit is indeed really nice but I wonder if the required customization, workflow tradeoff and (I assume??) lack of a source level debugger makes it not worthwhile.

 

[uyjulian]

This is very interesting, thanks.

I have a question.  Why mess about with retro68 etc. at all?  I do a lot of vintage 68k dev on modern Macs lately ... I do it by just running vintage Symantec C++ 7 in Basilisk II on my MacBook Air.

Is it just that you want to use a modern text editor?  BBEdit is indeed really nice but I wonder if the required customization, workflow tradeoff and (I assume??) lack of a source level debugger makes it not worthwhile.

Latest GCC has more proper support for language features and has more optimizations.

Also, it has a higher possibility to be automated with Continuous Integration compared to older toolchains.

 

[Crutch]

A matter of taste, I'm sure, but I'm of the opinion that serious optimization of vintage 68k software is best done by writing 68k assembly.  

If the desire is to use C++17 or other modern language features, of course, I get it.

(Another option just to use a better editor would be to use BBEdit on a modern Mac to edit files in a shared directory then switch to Basilisk II and run Symantec/MetroWerks C++ to compile/debug/run files in that same shared directory.)

 

[Frobozz]

I have a question.  Why mess about with retro68 etc. at all?  I do a lot of vintage 68k dev on modern Macs lately ... I do it by just running vintage Symantec C++ 7 in Basilisk II on my MacBook Air.

Is it just that you want to use a modern text editor?  BBEdit is indeed really nice but I wonder if the required customization, workflow tradeoff and (I assume??) lack of a source level debugger makes it not worthwhile.

That's a legit question. For me, not speaking for anyone else, part of the answer is usually "because I can". So, partly about the journey, if you will. 

But on a practical level, here are some of the reasons I prefer cross-compiling to native-on-retro-hardware (even if virtual): 

• version control. This is reason 1, 2, and 3. Maybe something is possible with Basilisk, since it can mount a shared Mac folder, but I haven't used Basilisk in 15 years or so, so I'll have to play around with that idea. Files with resource forks are going to be a challenge of course. (mini vMac doesn't support a shared folder, so I haven't ever tried that). 
  
• color syntax highlighting
  
• modern editor conventions
  
• speed (compiling, and just navigating/doing stuff)
  
• if my code crashes the target machine, it doesn't slow me down at all. Don't lose code, don't have to wait for reboot, etc. 
  
• more modern C
  
• C++ (less so for Macs, more so for Amigas)
  
• much better editors (very much less so for Macs, more so for Amigas)
  
• Prefer not to have the layer of the emulator between my mouse/keyboard/brain and the code editor. 
  
• Modern IDEs have some really nice features
  
• More tools for static checking/analysis (cppcheck, duplo, etc.)
  
• I like to keep all my code for all platforms together, if possible, instead of spread out all over the place. 
  

Some non-reasons:

• debugger. On the Amiga side, we have a gdb debugger server for the Amiga, and with Eclipse, you can run live debugging right on the Amiga. Unfortunately, I'm not aware of a similar functionality available for retro Macs. A good debugger is worth a lot, has to be said. 
  
• code optimization. My feeling about this is that while LLVM (and other modern compilers, presumably) can produced highly optimized (for performance) C++/C code, in doing this, they blow up the size of the compiled app. That makes zero difference on modern machines, but on any classic machine, that's a big deal. I mentioned I do Amiga dev with GCC via Eclipse. I also compile the same code using vbcc. The vbcc output is 1/10th the size of the gcc output (at least for the app I'm working on at the moment). I haven't done any benchmarking, but I'm perfectly willing to believe the GCC one runs slightly faster. 
  
• Err, that's about it, really. 
  

I'm not sure what workflow tradeoff you have in mind, but it's quicker for me to cross compile and run it than it is for me to compile with THINK C 5 on a Mac, or compile with SAS/C on the Amiga. Yeah, you have to do some initial setup work, and that can be a pain. But once it's set up, I dunno, it's pretty magical IMHO. 

 

[cheesestraws]

On the Amiga side, we have a gdb debugger server for the Amiga, and with Eclipse, you can run live debugging right on the Amiga. Unfortunately, I'm not aware of a similar functionality available for retro Macs. A good debugger is worth a lot, has to be said. 

"gdb" and "a good debugger" being right next to each other made me laugh quietly to myself, it must be said.  In its slightly odd little way, THINK Pascal's debugger is still probably the best I've ever used, and CodeWarrior's isn't bad, either.  Quality of debugging tooling in general is where the GNU toolchain badly falls down, especially when cross-compiling.

More generally, I find it very interesting that you're comparing with the Amiga a lot.  Mac development tooling got a lot more mature and featureful than anything the Amiga ever had; not meant as a fling at that platform, of course—the same is true of the Atari ST, especially the early Digital Research tooling—but a combination of Apple setting fairly high standards for dev tools fairly early and, I suspect, there being more money sloshing about in the ecosystem in general meant that the tooling got better.

Eclipse

Though I suspect that at least with software engineers around here, you may simply find you have an irreconcilable æsthetic difference here.  Personally, I find the idea of using Eclipse in my spare time absolutely horrifying...

 

[Frobozz]

"gdb" and "a good debugger" being right next to each other made me laugh quietly to myself, it must be said.  In its slightly odd little way, THINK Pascal's debugger is still probably the best I've ever used, and CodeWarrior's isn't bad, either.  Quality of debugging tooling in general is where the GNU toolchain badly falls down, especially when cross-compiling.

More generally, I find it very interesting that you're comparing with the Amiga a lot.  Mac development tooling got a lot more mature and featureful than anything the Amiga ever had; not meant as a fling at that platform, of course—the same is true of the Atari ST, especially the early Digital Research tooling—but a combination of Apple setting fairly high standards for dev tools fairly early and, I suspect, there being more money sloshing about in the ecosystem in general meant that the tooling got better.

Though I suspect that at least with software engineers around here, you may simply find you have an irreconcilable æsthetic difference here.  Personally, I find the idea of using Eclipse in my spare time absolutely horrifying...

I suppose that sentence would have been better without the "good". A debugger, period, is worth a bit. And yeah, Eclipse is a bit of an 'acquired taste', shall we say. I actually have a pretty good feeling about visual studio code (I just wish I could make it work for Retro68). 

back in the day, I didn't really program for either platform. I had both, used both regularly, but wasn't doing any real dev on them. A few years ago I got the bug and started doing C-128, Amiga, and Mac 68K programming for fun. So no baggage. It has been REALLY interesting having a foot in each community and platform (set aside the 8 bits for now). I wonder if Amiga programmers ever had any idea how much more refined the Apple developer tools/approach/whatever was. yes, 3rd party tools as you mentioned, but also THE DOCUMENTATION. Again, not making any judgments about which hardware / software was better. I love them both! I think the approaches just appealed to different types, and of course, the cost of entry was a big deal back then. it's hard to fathom how much we paid for computers back then, and the price difference between "similarly equipped" Macs and Amigas was huge. Well, that money went somewhere. 

 

[Crutch]

That's a legit question. For me, not speaking for anyone else, part of the answer is usually "because I can". So, partly about the journey, if you will. 

But on a practical level, here are some of the reasons I prefer cross-compiling to native-on-retro-hardware (even if virtual): 

• version control. This is reason 1, 2, and 3. Maybe something is possible with Basilisk, since it can mount a shared Mac folder, but I haven't used Basilisk in 15 years or so, so I'll have to play around with that idea. Files with resource forks are going to be a challenge of course. (mini vMac doesn't support a shared folder, so I haven't ever tried that). 
  
• color syntax highlighting
  
• modern editor conventions
  
• speed (compiling, and just navigating/doing stuff)
  
• if my code crashes the target machine, it doesn't slow me down at all. Don't lose code, don't have to wait for reboot, etc. 
  
• more modern C
  
• C++ (less so for Macs, more so for Amigas)
  
• much better editors (very much less so for Macs, more so for Amigas)
  
• Prefer not to have the layer of the emulator between my mouse/keyboard/brain and the code editor. 
  
• Modern IDEs have some really nice features
  
• More tools for static checking/analysis (cppcheck, duplo, etc.)
  
• I like to keep all my code for all platforms together, if possible, instead of spread out all over the place. 
  

Some non-reasons:

• debugger. On the Amiga side, we have a gdb debugger server for the Amiga, and with Eclipse, you can run live debugging right on the Amiga. Unfortunately, I'm not aware of a similar functionality available for retro Macs. A good debugger is worth a lot, has to be said. 
  
• code optimization. My feeling about this is that while LLVM (and other modern compilers, presumably) can produced highly optimized (for performance) C++/C code, in doing this, they blow up the size of the compiled app. That makes zero difference on modern machines, but on any classic machine, that's a big deal. I mentioned I do Amiga dev with GCC via Eclipse. I also compile the same code using vbcc. The vbcc output is 1/10th the size of the gcc output (at least for the app I'm working on at the moment). I haven't done any benchmarking, but I'm perfectly willing to believe the GCC one runs slightly faster. 
  
• Err, that's about it, really. 
  

I'm not sure what workflow tradeoff you have in mind, but it's quicker for me to cross compile and run it than it is for me to compile with THINK C 5 on a Mac, or compile with SAS/C on the Amiga. Yeah, you have to do some initial setup work, and that can be a pain. But once it's set up, I dunno, it's pretty magical IMHO. 

Thanks for this thoughtful response.  I hear you on the “because I can” thing.

Here’s my setup:

• I run Symantec C++ 7 under 7.5.5 in Basilisk II on a 2020 MacBook Air.  
  
• Popupfuncs + Technicolor provides syntax coloring and makes it easy to jump around my code (or, CodeWarrior includes that stuff baked in ... but I’ve always liked the Symantec tools a bit more).  
  
• The text editor is fine.
  
• The debugger is really quite nice also.  
  
• The speed is lightning fast, compiling 12,000 lines of code in probably 1 second, I don’t usefully need it to be any faster.
  
• Emulator crashes are a common thing but again, the emulator is so fast I will have restarted the emulated machine in about 3 seconds after the crash.  
  
• I put my Symantec C++ project file + THINK Reference + ResEdit in “Startup Items” so when I start my session or after any crash, I am instantly back in my dev environment and ready to fix the problem.
  
• My Basilisk II hard drive disk image file sits in my iCloud, so is automatically backed up continually - no risk of losing anything.  (For versioning, I duplicate my project directory occasionally and save it to my shared folder.)
  

Mostly I am surprised by your comment about speed, these emulators are so quick on modern hardware I have never had to wait for anything working as above.

I would like some code linting type features, but I would probably use Basilisk’s shared folder and use a modern tool to do that as a one-off when close to done with a project, I think.

 

[cheesestraws]

I actually have a pretty good feeling about visual studio code (I just wish I could make it work for Retro68). 

I hear very good things about VSCode from people at work, but it hasn't been enough to get me off BBEdit yet .

 

[Mu0n]

Some more modern IDE features I've come to love that could apply here:

1) autocomplete function labels (detects those labels and offer method names if part of a structure or class)
2) autocomplete functionargument types
3) squiggly lines on bad types in an assignment with the equal sign
4) highlight a function, or variable and go to its exact definition with a hotkey
5) navigate back across the history of where you were reading with a hotkey; navigate in both directions
6) auto detection of what header/source file you need when a known function is typed out; add it with a hotkey or context menu option