Updated Makefile and docs for fedsd utility

[ChadliaJerad]

When installing the tracing executables to /usr/local/bin, fedsd will not work, because it is operating on a dangling symlink.

This PR provides a fix.

[ChadliaJerad]

BTW, launch-fedsd.sh script is broken, since it relied on the paths to fedsd.py and trace_to_csv executable being known.
Will work on this.

[ChadliaJerad]

It works this way, but seems more like a hack...

[edwardalee]

One problem with the fix to the Makefile is that now a file in /usr/local/bin is a symbolic link into a user's clone of the repo. This seems problematic to me. Would it work instead to copy launch-fedsd.sh into /usr/local/bin (or wherever is specified with INSTALL_PREFIX)?

Also, for the other changes that try to prepend a path to trace_to_csv using an INSTALL_PREFIX argument to fedsd, this seems awkward. If trace_to_csv is in the user's PATH, it seems like it would not be necessary. Can we just check to see whether trace_to_csv is in the user's path and issue a friendly error message if not?

[erlingrj]

I am sorry about this. I didnt test the fedsd utility. I think I agree with Edward, it is not unreasonable to demand that for fedsd to work, certain executables must be on the PATH.

[erlingrj]

What is, btw, the reason for having this launch shell launch-fedsd.sh script wrapping a Python script fedsd.py instead of making the Python script itself executable and putting it on the PATH?

[erlingrj]

The Zephyr test failure is fixed by updating LF ref here: #263

[lhstrh]

What is, btw, the reason for having this launch shell launch-fedsd.sh script wrapping a Python script fedsd.py instead of making the Python script itself executable and putting it on the PATH?

No need for the launch script, IMO. Let make install copy the Python script and be done with it? Make sure it allows for specifying an installation prefix...

[edwardalee]

What is, btw, the reason for having this launch shell launch-fedsd.sh script wrapping a Python script fedsd.py instead of making the Python script itself executable and putting it on the PATH?

No need for the launch script, IMO. Let make install copy the Python script and be done with it? Make sure it allows for specifying an installation prefix...

Can a python program be made executable? I was unaware of that... How does the OS know which python to invoke?

[lhstrh]

Can a python program be made executable? I was unaware of that... How does the OS know which python to invoke?

https://realpython.com/python-shebang/

[ChadliaJerad]

Just pushed a fix, where launch-fedsd.sh is no longer needed.
I have a question though. Since executing Python Scripts with a shebang under Windows requires an extra configuration effort, where shall we mention this?
I thought this is the reason behind using the launch scripts...

A detail worth mentioning in this update is that one does not need saying fedsd *.lft anymore. Calling fedsd without arguments will automatically search .lft files. At the same time, it is still possible to operate of specific trace files that are given as arguments.

Regarding fedsd_helper.py, it is also copied with fedsd.py. Should we simply keep one file by putting the contents of the first in the second?

[lhstrh]

Just pushed a fix, where launch-fedsd.sh is no longer needed. I have a question though. Since executing Python Scripts with a shebang under Windows requires an extra configuration effort, where shall we mention this? I thought this is the reason behind using the launch scripts...

What configuration effort? On Windows, a bash script must be executed in WSL, and in WSL running a script with a #! doesn't require any configuration. The file must be executable (+x) though.

[ChadliaJerad]

What configuration effort? On Windows, a bash script must be executed in WSL, and in WSL running a script with a #! doesn't require any configuration. The file must be executable (+x) though.

Yes yes, you're right! Same for Cygwin.
Actually, I don't have a decent understanding of LF support on Windows platform...

[lhstrh]

What configuration effort? On Windows, a bash script must be executed in WSL, and in WSL running a script with a #! doesn't require any configuration. The file must be executable (+x) though.

Yes yes, you're right! Same for Cygwin. Actually, I don't have a decent understanding of LF support on Windows platform...

Since the introduction of WSL, there is a whole lot less to worry about. We can just tell Windows users to use WSL...

[lhstrh]

To build confidence in multi-platform support, just add some tests in CI and let them run them on all platforms. I don't believe there are currently any tests, so please add those.

[lhstrh]

Modulo suggestions, this looks good, but there are still no tests, so we don't have any assurance that this works and will keep working...

[lhstrh]

Since it appears that what's in main is broken and this is a fix, let's merge this. But we do need tests.

Comment has been addressed.