Sorry if this is a really basic question! Is there a way to modify my .t3m file and/or compiling options so that I don’t need to rebuild the adv3 library files on every single build?
Revealing my ignorance of how the underlying data works, if the adv3 library can be precompiled, will ‘modify’ and ‘replace’ within my own source files still have the normal effects?
Unless you have used that specific parameter to always rebuild object files (-a I believe), this should happen per default.
But I have had the issue (and several others in this forum) where the compiler (t3make) on a Mac always rebuilds all files anyway. In my case it only helped to reinstall the os unfortunately.
Have you set the -Fo parameter and created an obj directory by the way? It might help if you provide your current t3m file.
If it is supposed to only compile changed files by default, I’m pretty definitely sure that’s not what it’s doing right now, the compiler takes several seconds per build and scrolls through a long list of files. Thanks for any help!
I had not seen that thread, but it sounded like at the end, there was no definite solution. Maybe it’s just an unresolved issue on Mac systems? I also don’t know how to check if Endpoint is something active in my system. FileVault appears under my security settings, but it’s turned off.
Thanks for taking the time to answer…
Seems like it, my only experience of this is that worked with an older macOS but the one I had a couple of releases ago of the macOS (1-2 years ago) caused the bug, but it disappeared when I did a complete reinstallation some months ago. I hope there is someone with more insight of this that can respond. Otherwise it seems like a lead to see if the t3m file’s modification date keeps changing each build as it seems that could trigger a complete rebuild. If so, maybe you could try to write protect it… it’s an ugly workaround but maybe can make life a bit easier if it works.
I have had FileVault turned on for my Macs for the past three years or so. It definitely doesn’t affect filesystem mod dates. If it did, it would screw up Makefiles and many other sorts of build tools.
Is TADS maybe looking at the ctime (metadata change time) as well as the mtime? That would be a bizarre decision, but it might lead to this sort of problem.
EDIT-ADD: Nope, can’t see any sign of that in the source. It relies entirely on mod_time.
I tried to turn off write access to the t3m file… didn’t fix it. I guess short of trying a new operating system install I’ll just have to spend an extra half-hour or so of my life watching the compiler window scroll down… Thanks again for suggestions…
Good news! I think I found what the problem was and a workaround for it. I was using an older version of macos before but upgraded recently to the latest and got this issues back again. This time I thought I should investigate it a little further. I started suspecting it had something to do with accessing the global folder "/usr/local/share/frobtads/tads3/" and it turned out that was right. If you for instance do a clean copy of the whole tads3 folder just mentioned to your home folder and then prefix all your search paths in your Makefile.t3m file with /Users//tads3, e.g:
then the compile issues will go away! (At least they did on my machine.)
I’m guessing this has to do with some level up in security aspects of accessing folders from applications that’s been introduced in newer MacOS versions.
Yes!! This is one of the best Christmas presents I’ve gotten this year! Wow, I could not count how many hundreds if not 1000+ times I’ve recompiled the whole adv3 library and all my source files for every little change-and-test over the last year and a half! Thank you Tomas! Watching my game recompile almost instantly is practically beyond belief. Please accept a virtual hug of gratitude!
Glad to hear it! Virtual hug accepted! Now I just hope everone else who have had these issues will come across this post, and hopefully someone knows what’s up with the latest macos:es and what to do about “/usr/local/”.
The one thing one could do if compiling frobtads locally is to set the -DCMAKE_INSTALL_PREFIX="/Users/username" (or some other global directory that’s not causing problems) instead of the default “/usr/local”. But if if installing with homebrew I guess the formula needs to be changed. (Actually I don’t like the idea of curing the symptom of the problem but I guess this extra step is the fastest way forward for now.) I’ll add this issue to the frobtads git repository as well.