Closed crazzell closed 7 years ago
mherger
commented
7 years ago Instead of copying the same code in several script, could the update procedure become its own script which then is called from the others? I'm sure the if statement will soon be an update to cover some other platform than aarch64. We'd then have to update a single script, rather than a dozen of them.
crazzell
commented
7 years ago Yes, that might be a better approach although I womder where would that common script should be located? Perhaps in the CPAN directory, and have the Flac, Sox and Wavpack buildme-linux.sh scripts reference it as ../CPAN/update_config.sh ? Are we safe to assume the entire slimserver-vendor directory structure is replicated on the build host, or should each helper binary build directory avoid file dependencies outside of itself?
If we do use a such a shared update script, I assume it would have to be a Bourne (not Bash) Shell script for maximum compatibility? Note that the buildme-linux.sh scripts for the helper binaries are currently Bourne shell scripts according to their #! lines.
Charles.
On Thu, Nov 2, 2017 at 11:12 PM Michael Herger notifications@github.com wrote:
Instead of copying the same code in several script, could the update procedure become its own script which then is called from the others? I'm sure the if statement will soon be an update to cover some other platform than aarch64. We'd then have to update a single script, rather than a dozen of them.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Logitech/slimserver-vendor/pull/30#issuecomment-341628684, or mute the thread https://github.com/notifications/unsubscribe-auth/AAS0MjMmg505NLY00kU5FMMgpRLYHnDuks5syq7OgaJpZM4QJJ5Q .
mherger
commented
7 years ago These scripts aren't run regularly on a build host. Those builds are done once, then included in LMS (or not). But they're nowhere used regularly. Therefore we can assume that the one guy running this won't re-organize the files before executing the script.
crazzell
commented
7 years ago Okay, I made the changes as suggested by your comments. Now, all updating is handled by one script, (update-config.sh). I sourced this new helper script rather than executed it so that the random suffix of the config.guess and config.sub filenames generated using $$ would stay constant for any given build. Please review and merge if you see fit. Thanks.
mherger
commented
7 years ago I'm still waiting for my Rock64... thanks for your effort!
crazzell
commented
7 years ago Michael, would you consider doing the merge prior to obtaining your dev board? Given that my change set was written with "do no harm" as the primary design objective, it would be good to test that existing builds continue to build without side effects. If you merge in these changes and there are no unwanted side-effects then there is no harm done. If you do see some issues, let's fix them sooner rather than later, would be my suggestion.
BTW, I did rebase, and I am now 13 commits ahead (and 0 behind) Logitech:public/7.9.
I've tried to make these changes a minimal and low-impact as possible.
The idea is to simply copy in from the latest config.guess and config.sub files from their source repos on the web at http://git.savannah.gnu.org/, but to do so only on platforms that wouldn't otherwise compile. There should therefore be no unwanted side effects on other platforms.
I created a bash function inside CPAN/buildme.sh named refresh_config(), that does the conditional copying of the files using wget.
Other possibilities were considered such as actually running automake to regenerate the configure scripts, which in some sense is the more "proper" approach, but this assumes a working automake, and would be more likely to fail IMO.
Similar fixes were applied in the buildme-linux.sh for flac, sox and wavpack, but I did not use function calls in those cases, as I would need to change the script interpreter from Bourne shell to Bash, which may or may not be a good idea.