library paths and ‘Export.APCS-32’ stuff

In the recent 5.25 & latest DDE the paths for various libraries as set by !SetVars are all pointing to {blah.blah}.Export.APCS-32 rather than the prior locations.

At the most trivial level this means that my locating ‘rink’ as a sibling of Libraries.CLib and referring to it in a Makefile as “C:^.rink” no longer works, whcih was why I spotted the change. More seriously I’ve not been able to find anything explaining what the change means or more importantly how it affect OSLib and rink. Are libraries now required to be compiled differently?

What’s the deal here?

If you don’t get a reply here, try e-mailing the ctools e-mail address at riscosopen.org

I’d like to help, but my knowledge is limited. I tried googling for “rink” but none of the results were plausible and unfortunately it’s a very common word as well as being a surname, it appears!

The DDE has been pointing C$Path to Export for a long time. When you compile your own roms C$path is changed by !Builder to point to the Export Directory in the ROM Sources so I suppose the library tree was standardised. Can’t you just set Rink$path to your rink library when booting or make a little application which sets rink$path when seen and include -IRink: when compiling your programs? OSLib may have its own path variable. I wouldn’t rely on the location of C$path to find additional libraries especially if you compile your own roms as it changes.

OSLib may have its own path variable.

Yes. There are little obey files in both OSLib and OSLibSupport that set the paths appropriately.

I leave C$Path for the actual DDE stuff. All my own libraries have their own path variables set during boot, and all the header files to include (and obj files to link) are referred to by the path e.g. PNGLib:o.pnglib. I started doing this a long time ago, initially because of name clashes between DDE libs and e.g. OSLib, where the ‘wrong’ include file was being found.

OK, the good news is that tweaking my Makefile to not refer to rink via C: worked and it even produces a Squeak VM that runs. So no big issue with APCS-32 stuff thatI can find as yet. This is good.

More generically, why doesn’t the !SetVars look in each library subdirectory and run any !SetVar obey file it finds, thus allowing a nice simple modular approach to adding libraries?

What is this “logic”? We don’t like your sort around here! :P

Oh come on, be nice to a newcomer; I’ve only been doing RISC OS stuff since it replaced Arthur…

Hmmm, how many development environments does this resemble?

https://m.xkcd.com/1987/

I just knew our project “planners” and “managers” had nicked a plan from somewhere and changed the text.
Now I know where from…