problem using _kernel_oscli

The question in my mind is:

Is it reasonable to expect that a RO programmer who wishes to, could generate a RO version of flac from the xiph source tarballs? The entry qualification for ‘reasonable’ and ‘programmer’ would, I assume mean that said programmer had a level of skill equivalent to a Linux/Windows/Mac programmer that would be required to do so for those platforms.

If the above is reasonable, then it seems fair to me that I could include the compiled flac and point people to xiph if they want sources. Alternatively it might be more convenient for the future if I had a link from which people could get the complied flac utility for RO, along with a note and links to the riscos.info and xiph sites for source code, etc. That way people who wanted any new version of !Flac_HealthCheck wouldn’t have to download another zip enlarged by including a copy of flac that they already have.

However I’ve never done anything like build flac from such sources or use an ‘autobuilder’ beyond doing a make of something like ffmpeg on Linux. So I’d welcome comments on this from you or other programmers who’ve ‘ported’ such items for RO.

Jim

That way people who wanted any new version of !Flac_HealthCheck wouldn’t have to download another zip enlarged by including a copy of flac that they already have.

You already have that functionality with the downloadable packages. If the version number is of serious concern to RISC OS users, you could mention it on the gcc mailing list.
But even Linux users just use the version that their distribution installs, unless you do a manual build of the very latest.
Keep in mind that if the autobuilder flac was fixed at 1.3.1, it will only be a matter of time and that would become old, and it wouldn’t move from that version as it would do with the normal migration of new packages.

Generally one needs to install the autobuilder and crosscompiler as per the instructions on riscos.info. Some sources are very port friendly, and the process is the same as in Linux. I use ~/ron/gccsdk/env/ro-config, ro-make, ro-make install (for a lib) instead of ./configure make etc.
As in Linux you would check what configure options may be of use.
That is a job that would normally be done by the linux installer or in our case, the autobuilder.
I installed 4.7.1 recently following the instructions without a problem. Using a linux not related to debian/ubuntu may have some package name differences.

I’ve just put up a new version of !Flac_HealthCheck which fixes a problem with the earlier version.

I’ve also added some links so that people can decide how they want to get flac and/or its sources. Hope this makes life easier for users.

The main change is that I wrote some code to read the header of a flac file so I could determine the file details before calling the flac utility. Then used that info to ensure the program read the entire file’s data payload.

Jim

I’ve also added some links so that people can decide how they want to get flac and/or its sources. Hope this makes life easier for users.

I don’t know if you have noticed, Jim but there is a newer (1.3.0) package available which includes a lot of html docs.
In my player app I have included a link http://www.riscos.info/packages/AudioDetails.html#FLAC rather than the explicit zipfile, so it doesn’t get old.
As long as !FLAC is in a directory that has been opened it will filer boot and be found. If I was relying on this alone I could check for it with
If alias$flac = "" Then Error !FLAC package not found
but to allow for someone just putting the flac binary in the run path, I am using
flac -v { > null: }
Which stops the obey file with the error ‘File flac not found’.
Edit: There is a complication when checking for the bare binary, that a large enough wimpslot may not be allocated yet so I need to delay this check until the wimpslot is established. In my case this would be the obey file called by taskwindow, but the check becomes redundant, as a similar error will be reported by trying flac with the audio anyway.
You can see an advantage to having wimpslot set in the !FLAC alias, as long it works in all useage cases.

Using !FLAC /does/ avoid including the binary (which could get old) with my app, and reduces the app size dramaticly of course.