Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[feature] Prevent hardcoded install #1431

Open
wants to merge 1 commit into
base: testing
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion CMakeLists.txt
Original file line number Diff line number Diff line change
Expand Up @@ -348,7 +348,7 @@ install(TARGETS st-trace DESTINATION ${CMAKE_INSTALL_BINDIR})
# Device configuration (Linux only)
###

if (CMAKE_SYSTEM_NAME STREQUAL "Linux")
if (CMAKE_SYSTEM_NAME STREQUAL "Linux" AND NOT PREVENT_HARDCODED_INSTALL)
Copy link
Member

@Nightwalker-87 Nightwalker-87 Oct 3, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It appears that this is a self-defined cmake command. It needs to be documented before having it added to the code. Also this topic should be discussed in general.

Copy link
Author

@sansyse sansyse Oct 4, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's just an environment variable that, if defined non-null, prevents this install. It works.

In my opinion, it is not a good practice, if a build process of a development tool needs root privileges and forces modifications on the host system. Due to security reason, I never ever run such a build process with root privileges, in particular if you have not reverse-engineered the installation process and know exactly which modifications are done. I'm working on several different projects on the same development host and need to track modification manually. On the other hand a good practice is, if a project can installed relatively for packatizing, archiving, in-docker installation and/or project-local use. The modification on the host system is only done once (fully intentional), but the build process and debugging is done regularly and should never be done with root privileges.
In my environment the stlink stuff are archived in the project together with sources and other resources and the build and installation process of stlink tools are part of the project build. It is installed locally only.

STLINK_INSTPREFIX = $(abspath host)
STLINK_CMAKEFLAGS = -DCMAKE_INSTALL_FULL_DATADIR=$(STLINK_INSTPREFIX) -DCMAKE_INSTALL_PREFIX=$(STLINK_INSTPREFIX) -DPREVENT_HARDCODED_INSTALL=1

... make -j1 CMAKEFLAGS="$(STLINK_CMAKEFLAGS)" release install

I agree, that a hobbyist or standard-user may do not need such a feature and for him it would be safer to install everthing in one automated installation process. But there are also experienced users with non-standard use cases.
A compromise and maybe better solution would be, to use the sysconfig_dir feature in you installation script to use it like this:

STLINK_INSTPREFIX = $(abspath host)
STLINK_CMAKEFLAGS = -DCMAKE_INSTALL_SYSCONFDIR=$(STLINK_INSTPREFIX)/etc -DCMAKE_INSTALL_FULL_DATADIR=$(STLINK_INSTPREFIX) -DCMAKE_INSTALL_PREFIX=$(STLINK_INSTPREFIX)

... make -j1 CMAKEFLAGS="$(STLINK_CMAKEFLAGS)" release install

## Install modprobe.d conf files to /etc/modprobe.d/ (explicitly hardcoded)
set(STLINK_MODPROBED_DIR "/etc/modprobe.d" CACHE PATH "modprobe.d directory")
install(FILES ${CMAKE_SOURCE_DIR}/config/modprobe.d/stlink_v1.conf DESTINATION ${STLINK_MODPROBED_DIR})
Expand Down
Loading