updating documentation with new mlir-aie build script

[eddierichter-amd]

Updating the documentation to be consistent with the new build-mlir-aie-local.sh script.

[erwei-xilinx]

Make sense to me. I guess a related question might be when an open source user tries to clone a libxaie from the github-clone-build-libxaie.sh, then it might not necessarily be in /opt. I wonder if we should add some comment in the doc to explain that you can build libxaie yourself, and replace the /opt/xaiengine with something like /path/to/libxaie/install?

[eddierichter-amd]

Make sense to me. I guess a related question might be when an open source user tries to clone a libxaie from the github-clone-build-libxaie.sh, then it might not necessarily be in /opt. I wonder if we should add some comment in the doc to explain that you can build libxaie yourself, and replace the /opt/xaiengine with something like /path/to/libxaie/install?

Good point. Do we want users running the github-* scripts? I was under the impression that those were just for the github actions. The way that I have been looking at it is that in the building documentation (https://github.com/Xilinx/mlir-air/blob/main/docs/building.md#building-on-x86-with-runtime-for-pcie) we direct the user to install libxaie in /opt/ so was thinking it was fine to use it as a path in the documentation. I will add some additional clarity in the documentation to make it clear that it can be installed elsewhere.

[erwei-xilinx]

Make sense to me. I guess a related question might be when an open source user tries to clone a libxaie from the github-clone-build-libxaie.sh, then it might not necessarily be in /opt. I wonder if we should add some comment in the doc to explain that you can build libxaie yourself, and replace the /opt/xaiengine with something like /path/to/libxaie/install?

Good point. Do we want users running the github-* scripts? I was under the impression that those were just for the github actions. The way that I have been looking at it is that in the building documentation (https://github.com/Xilinx/mlir-air/blob/main/docs/building.md#building-on-x86-with-runtime-for-pcie) we direct the user to install libxaie in /opt/ so was thinking it was fine to use it as a path in the documentation. I will add some additional clarity in the documentation to make it clear that it can be installed elsewhere.

I think in some server settings, a user without sudo would not have access to /opt. I think it might be useful to clarify that /opt write access is not a requirement in order to build our tool.

[keryell]

I still have this Xilinx/mlir-aie#395
Since now I know this is the local practice to merge its own PR I can look again at it.

[eddierichter-amd]

Make sense to me. I guess a related question might be when an open source user tries to clone a libxaie from the github-clone-build-libxaie.sh, then it might not necessarily be in /opt. I wonder if we should add some comment in the doc to explain that you can build libxaie yourself, and replace the /opt/xaiengine with something like /path/to/libxaie/install?

Good point. Do we want users running the github-* scripts? I was under the impression that those were just for the github actions. The way that I have been looking at it is that in the building documentation (https://github.com/Xilinx/mlir-air/blob/main/docs/building.md#building-on-x86-with-runtime-for-pcie) we direct the user to install libxaie in /opt/ so was thinking it was fine to use it as a path in the documentation. I will add some additional clarity in the documentation to make it clear that it can be installed elsewhere.

I think in some server settings, a user without sudo would not have access to /opt. I think it might be useful to clarify that /opt write access is not a requirement in order to build our tool.

Great point. In 437919f added some additional commentary on where the library should be installed. Let me know what you think and feel free to add anything else.

[erwei-xilinx]

Make sense to me. I guess a related question might be when an open source user tries to clone a libxaie from the github-clone-build-libxaie.sh, then it might not necessarily be in /opt. I wonder if we should add some comment in the doc to explain that you can build libxaie yourself, and replace the /opt/xaiengine with something like /path/to/libxaie/install?

Good point. Do we want users running the github-* scripts? I was under the impression that those were just for the github actions. The way that I have been looking at it is that in the building documentation (https://github.com/Xilinx/mlir-air/blob/main/docs/building.md#building-on-x86-with-runtime-for-pcie) we direct the user to install libxaie in /opt/ so was thinking it was fine to use it as a path in the documentation. I will add some additional clarity in the documentation to make it clear that it can be installed elsewhere.

I think in some server settings, a user without sudo would not have access to /opt. I think it might be useful to clarify that /opt write access is not a requirement in order to build our tool.

Great point. In 437919f added some additional commentary on where the library should be installed. Let me know what you think and feel free to add anything else.

Looks great to me. Thanks.

[fifield]

Make sense to me. I guess a related question might be when an open source user tries to clone a libxaie from the github-clone-build-libxaie.sh, then it might not necessarily be in /opt. I wonder if we should add some comment in the doc to explain that you can build libxaie yourself, and replace the /opt/xaiengine with something like /path/to/libxaie/install?

Good point. Do we want users running the github-* scripts? I was under the impression that those were just for the github actions. The way that I have been looking at it is that in the building documentation (https://github.com/Xilinx/mlir-air/blob/main/docs/building.md#building-on-x86-with-runtime-for-pcie) we direct the user to install libxaie in /opt/ so was thinking it was fine to use it as a path in the documentation. I will add some additional clarity in the documentation to make it clear that it can be installed elsewhere.

The github-* scripts are not intended for users. They are for github actions.

[keryell]

The github-* scripts are not intended for users. They are for github actions.

At the same time we have a lot of scripts with a lot of copy-paste difficult to handle and keep in sync.
Even in the CI there are out-of-sync GitHup actions because it is difficult to keep in sync the common parts. :-(
So, anything that can produce less polymorphic adaptable scripts will have my vote. :-)

[fifield]

The github-* scripts are not intended for users. They are for github actions.

At the same time we have a lot of scripts with a lot of copy-paste difficult to handle and keep in sync. Even in the CI there are out-of-sync GitHup actions because it is difficult to keep in sync the common parts. :-( So, anything that can produce less polymorphic adaptable scripts will have my vote. :-)

My preference would be to not have scripts as documentation at all and only have the CI infra scripts (which are tested by design). Instead we should have docs that actually teach people how to set the cmake parameters for their situation (example). The problem with the scripts is they rarely work for more that one person's environment resulting in a set of PRs each time a new developer tries to "fix" them.

[erwei-xilinx]

Having such docs would be helpful. People like me may try to "fix" the scripts in a hope to make more people's envs work with this project. Open source users tend to say that the project doesn't work and just walk away.