Overall this looks good! I've built it myself on macOS and everything appears to be in order. Someone should also test on a Linux system to make sure.

One request -- can you add this? Otherwise the library will be created as liblibscide.a on macOS/Unix systems. It's a cosmetic thing but still nice to see.

set_target_properties(libscide PROPERTIES PREFIX "")

Thanks Brian

One request -- can you add this? Otherwise the library will be created as liblibscide.a on macOS/Unix systems. It's a cosmetic thing but still nice to see.

set_target_properties(libscide PROPERTIES PREFIX "")

Sure, I'll do that after the dev meeting...

I guess I'll have lots of rebasing to do before I can push the update anyway...

@brianlheim I've fixed the library name, rebased and force-pushed...

I'll ask on Slack to see if anyone can test the Linux build.

Is this OK to ask for a formal review now?

I just built this successfully on Linux. Here's what I did:

• cloned your fork and checked out your branch
• followed the Linux build instructions with no custom cmake flags (just cd'd to my build directory and ran cmake ..
• after this completed successfully, I ran make
  All these operations completed without error. Some warnings from make, but they look normal/non-related.

For good measure, I then ran sudo make install. I don't know if you care about this at this stage, but I get an interesting error when I run /usr/local/bin/scsynth or /usr/local/bin/sclang:

 chad@dax  ~/code/forks/supercollider/build   create_libscide  /usr/local/bin/sclang
compiling class library...
[1]    726762 bus error (core dumped)  /usr/local/bin/sclang
 chad@dax  ~/code/forks/supercollider/build   create_libscide  /usr/local/bin/scide
[1]    726872 bus error (core dumped)  /usr/local/bin/scide

Please let me know if there is anything missing or misunderstood with my test procedure. I'm happy to do further work. I'm on Arch Linux with kernel 5.3.1-arch1-1-ARCH.

@beatboxchad Hi, thank you very much for this - yes, I definitely care about the core dump... It would really help to know whether that existed prior to the changes I made...

Would you have time at some point to repeat that test but with this version, please?
7261756

Coming right up!

Just built on that revision, and the core dump does not take place.

Happy to help you troubleshoot this -- I'm a bit of a C++ noob, but it'd be great for me to learn. strace? set up a debugger? You can just tell me the high-level of what to do, I'll hit the search engine and flesh it out.

Thank you SO much for checking. Am really glad to have a chance to fix that before the change makes it to the dev branch.

I’m very new to SC so don’t have a lot of experience of strategies for it.

I did notice some suggestions on capturing logs after this recent message on SC Slack - though I don’t know if they are at all relevant to the crash you are seeing.

https://scsynth.slack.com/archives/C6F5X44RF/p1572733871189700

Another thing I have found really helpful in the past is to use git bisect to work out exactly which commit caused the crash... well, it was hg bisect I used, but the principlEs will be the same.

One last thing for now - a fantastic thing to aid tracking this down is that you have both a working and a non-working program, which can really help speed up tracking down problems, by comparing various aspects of the two.

The changes I made were not supposed to change the layout of the install at all, but it might be worth using some recursive diff tool to compare the working and broken install folders, to see if any files have ended up in the wrong place or missing.

If you can find out how to create a log file of the various SC components, you could also run the two and compare the difference in the two logs, which might be revealing.

Apologies for taking up your time on this - but Yay for testing!!!

No apologies needed, these are great warmups for me. We're both new contributors. Thank you for the opportunity!

Forgot to thank you for all the awesome troubleshooting tips, too. \m/

Hey @claremacrae good news! I didn't even have to use all your great advice -- before I went full git bisect it occurred to me to check for low-hanging fruit. That minor change you made based on feedback, after you did all the well-thought-out work, that's the one that always gets me too. So I just walked back one commit and built->installed, and it looks like cd86d90 introduced the core dump.

Now we can reason about why. Something something linking on Linux something something.

Hey @beatboxchad - that’s awesome work. Thank you very much indeed!

As the new library is statically linked and the file name is really a hidden thing, I wonder whether it would be acceptable to revert the library filename change, instead of debugging the crash further ?

@brianlheim When you have a minute, I’d really appreciate your view. Many thanks, both.

That sounds like a bug in the build system if you have to a clean build after changing the code.

Weirdest thing -- I can't seem to reproduce that core dump any more. I'm switching between revisions on your branch. I'm running make clean between builds, using make uninstall.

I'm too new to reason about what could have caused this, but the reason I looped back is because I couldn't reproduce the core dump on the latest build any more.

Any ideas?

Wanting to make sure it wasn't something I did on my workstation, I just went and cloned -> built it on my Linode running Arch Linux (PS anybody who wants to try this, all you gotta do is run a VNC server and export DISPLAY=:1 so it'll run). It built and ran fine.

I've really got no clue what caused that core dump before, but I can't reproduce it now. I'm comfortable saying this builds fine on Linux.

thanks for the persistence @beatboxchad !

In view of Chad's successful testing on Linux, is there anything else that I need to do with this, or would it be possible for someone to merge it please?