would be nice if SDCC behaved a little like busybox and
automatically set its target port if it's called with a
different name?
So you could do something like:
ln -s /usr/local/bin/sdcc /usr/local/bin/ds390-sdcc
ln -s /usr/local/bin/sdcc /usr/local/bin/picxx-sdcc
ln -s /usr/local/bin/sdcc /usr/local/bin/hc08-sdcc
ln -s /usr/local/bin/sdcc /usr/local/bin/z80-sdcc
and SDCC would behave as if its -m option had been set
(prefixing the port name as gcc does) when it's called
f.e. as z80-sdcc
Logged In: YES
user_id=589052
Hi,
as long as Sourceforge's CVS is down I might as well add a
patch.
It adds a dependency on <libgen.h>. I have no clue about the
implications of this dependency, so maybe it's not bad to
submit it as a patch anyway.
in svn revision #5473.
Leaving the request open for now because I couldn't check with Windows and because "make install" does not set the links (do we want to?)
WIN32 fix in svn revision #5474.
Borut
Frieder,
in the current implementation the target defined in the application name has higher priority then -m command line option:
"z80-sdcc -mmcs51 ..." generates code for z80 and not for mcs51.
I think it would be better if -m would have higher priority. This means just changing the sequence in function _findPort():
- try to assign port by the name of the executable
- try to assign port by command line option
Borut
Borut
Hi Borut,
thanks for #5474!
> ""z80-sdcc -mmcs51 ..." generates code for z80 and not for mcs51."
No, it already is as you want it to be:)
(The variable "found" is checked in the loop condition of the 2nd loop,
so a previously (by -m option) assigned port is not overriden.)
Greetings,
Frieder
Frieder,
you are right, I haven't noticed that the for loop is executed only if found is false.
Thanks for clarification.
Borut