16:11 <_whitenotifier-e> [whitequark/libfx2] carlossless 0aac428 - emit build/.d files through a separate command to enable compatibility with sdcc 4.3.0

16:11 <_whitenotifier-3> [whitequark/libfx2] whitequark pushed 1 commit to main [+0/-0/±1] https://github.com/whitequark/libfx2/compare/9167386d4f0b...0aac42849cd9

16:11 <_whitenotifier-3> [libfx2] whitequark closed pull request #15: compatibility with sdcc 4.3.0: emit build/.d files through a separate command - https://github.com/whitequark/libfx2/pull/15

16:12 <_whitenotifier-e> [libfx2] whitequark created tag v0.13 - https://github.com/whitequark/libfx2

16:12 <_whitenotifier-e> [whitequark/libfx2] whitequark tagged 0aac428 as v0.13 https://github.com/whitequark/libfx2/commit/0aac42849cd98122e5bbc4e94b92a109e88da463

16:13 <_whitenotifier-3> [libfx2] whitequark commented on pull request #15: compatibility with sdcc 4.3.0: emit build/.d files through a separate command - https://github.com/whitequark/libfx2/pull/15#issuecomment-1912318620

16:13 <_whitenotifier-3> [libfx2] whitequark commented on issue #11: build issue with latest sdcc svn version - https://github.com/whitequark/libfx2/issues/11#issuecomment-1912318909

16:13 <_whitenotifier-3> [libfx2] whitequark closed issue #11: build issue with latest sdcc svn version - https://github.com/whitequark/libfx2/issues/11

18:06 <vifino8434[m]> Huzzah! Glad to see libfx2 getting this change. That means I can bump sdcc in NixOS.

18:06 <whitequark[cis]> 🎉

18:08 <vifino8434[m]> I wish I could've figured that one out a while ago, but everything I attempted failed horribly. Glad to see a non-hacky fix.  

18:09 <whitequark[cis]> yeah I can see it being frustrating

18:09 <whitequark[cis]> kind of a really annoying type of issue where it makes every involved party unhappy for reasons that aren't directly in anyone's control

18:11 <vifino8434[m]> exactly! It was a pretty sucky situation, sdcc dropping stuff that shouldn't have been used for a long time but practically with no notice in a point release? that wasn't very semver :/

18:12 <whitequark[cis]> also the semantics of those flags wasn't super well documented in first place, i don't normally use obsolete flags

18:12 <whitequark[cis]> nor did i realize that sdcc copied gcc's preprocessor from some ancient version and then decided to not actually fork it

18:13 <whitequark[cis]> their decision to use sourceforge mailing lists contributed to my desire to never talk to them again (i submitted a patch that got rejected, no issue with the rejection, but the whole process was unnecessarily painful)

18:14 <whitequark[cis]> i think eventually sdcc's processes will become less 2005 but until that happens i'll just chill

18:14 <vifino8434[m]> yeah, i'm usually pretty good with (cursed) makefiles, but i stared at the sdcc documentation and mailing lists... it's bad

18:14 <whitequark[cis]> sdcc's docs are usually pretty good too, like all the compiler extensions for 8051? A+ documentation (mostly)

18:17 <vifino8434[m]> i only looked at the flags part of that sdcc pdf manual, so i couldn't say anything about the rest... but that was frustrating :/