Description of problem: Can't use sdcc without adding /usr/libexec/sdcc to PATH. Version-Release number of selected component (if applicable): sdcc-2.6.0-8.fc6 How reproducible: always Steps to Reproduce: 1. echo 'void main() {}' > t.c 2. sdcc-sdcc t.c Actual results: sh: sdcpp: command not found Expected results: No stderr output. Additional info: Having a command named "sdcc-sdcc" seems kind of weird?
I guess we should patch sdcc to exec helper programs with the full path under /usr/libexec/sdcc/ Or maybe there already is a configure flag todo this. > Having a command named "sdcc-sdcc" seems kind of weird? Agreed, I don't know how the average sdcc using Makefile looks, if it only invokes sdcc, for both compiling and linking, then it might be a good idea to rename this, however if it uses multiple sdcc commands its possibly best to leave this at is, having then Makfile find sdcc, but not the others would only confuse the user.
(In reply to comment #1) > I guess we should patch sdcc to exec helper programs with the full path under > /usr/libexec/sdcc/ What if the user wants to run any of the other sdcc-programs before running sdcc? > Or maybe there already is a configure flag todo this. There is no configure flag to do this atm. The name of the preprocessor is hard-coded in the SDCCmain.c-file. Changing it to sdcc-sdcpp would be very simple, and would still work if the user add /usr/libexec/sdcc to his or her path. > > Having a command named "sdcc-sdcc" seems kind of weird? > > Agreed, I don't know how the average sdcc using Makefile looks, if it only > invokes sdcc, for both compiling and linking, then it might be a good idea to > rename this, however if it uses multiple sdcc commands its possibly best to > leave this at is, having then Makfile find sdcc, but not the others would only > confuse the user. I agree too, but this was discussed during the review; see bug 226795.
(In reply to comment #2) > (In reply to comment #1) > > I guess we should patch sdcc to exec helper programs with the full path under > > /usr/libexec/sdcc/ > > What if the user wants to run any of the other sdcc-programs before running sdcc? > When I said patch sdcc, I meant the whole package not just the sdcc command itself, if any of the programs wants to execute others, it should be patched to be able to find those others even if /usr/libexec/sdcc/ is not in the PATH. > > Or maybe there already is a configure flag todo this. > > There is no configure flag to do this atm. The name of the preprocessor is > hard-coded in the SDCCmain.c-file. Changing it to sdcc-sdcpp would be very > simple, and would still work if the user add /usr/libexec/sdcc to his or her path. > That would be fine too, as long as all the programs can find any needed others > > > Having a command named "sdcc-sdcc" seems kind of weird? > > > > Agreed, I don't know how the average sdcc using Makefile looks, if it only > > invokes sdcc, for both compiling and linking, then it might be a good idea to > > rename this, however if it uses multiple sdcc commands its possibly best to > > leave this at is, having then Makfile find sdcc, but not the others would only > > confuse the user. > > I agree too, but this was discussed during the review; see bug 226795. Yes during the review it was discussed to prefix the program-names with sdcc- because most of the names are somewhat generic, however the name sdcc is not generic, so maybe an exception should be made for the sdcc command / program itself. But as said I think that depends on usage scenario, see my original comment.
(In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #1) > > > I guess we should patch sdcc to exec helper programs with the full path under > > > /usr/libexec/sdcc/ > > > > What if the user wants to run any of the other sdcc-programs before running sdcc? > > > > When I said patch sdcc, I meant the whole package not just the sdcc command > itself, if any of the programs wants to execute others, it should be patched to > be able to find those others even if /usr/libexec/sdcc/ is not in the PATH. > > > > Or maybe there already is a configure flag todo this. > > > > There is no configure flag to do this atm. The name of the preprocessor is > > hard-coded in the SDCCmain.c-file. Changing it to sdcc-sdcpp would be very > > simple, and would still work if the user add /usr/libexec/sdcc to his or her path. > > > > That would be fine too, as long as all the programs can find any needed others > I did some more testing, and it appares that all of the binaries have hard-coded names, so modifying everything is out of the question. The solution would therefore be to add scripts in /usr/bin/that adds /usr/libexec/sdcc to path and calls the corresponing binary. Any objections to this?
I think I have solved the problem, but I would like some feedback before submitting it to the repos. New spec and srpm at ftp://open-gnss.org/pub/fedora/sdcc
Looks good, but \"\$*\" should be \"\$@\" AFAIK, otherwise all the arguments to the script get passed as one argument to the real binary Also since the whole purpose of the whole libexec exercise was to not polute /usr/bin with common names I would put /usr/share/sdcc in front of the PATH in case other packages / make installs with similar names aren't that friendly.
New package has been pushed to extras.