Yocto配方中‘install’关键字的意义及与touch/mkdir的优势对比

Hey there! Let's break down your questions about the install command (it's technically a GNU coreutils tool, not a Yocto-specific keyword) step by step—this is such a common point of confusion since it’s not always front-and-center in some project docs.

What Is the install Command in Yocto Recipes? #

First off: install isn’t a Yocto-exclusive "keyword"—it’s a standard command from GNU coreutils that’s become a staple in Yocto’s do_install tasks. Its core job is to copy files/directories to a target location while automatically handling permissions, ownership, and even directory creation. It’s favored in recipes because it simplifies setting up files in the temporary target root filesystem (Yocto’s ${D} directory, equivalent to DESTDIR in build systems).

Advantages Over touch/mkdir #

Using install instead of manual commands like touch, mkdir, or basic cp has several key benefits for Yocto builds:

• Automatic permission management: By default, install sets executable files to 755 (read/write/execute for owner, read/execute for others) and non-executables to 644. Directories created with install -d get 755 permissions too. With touch or mkdir, you’d have to add extra chmod commands to get non-default permissions, which adds steps and room for error.
• Recursive directory creation: install -d creates all parent directories in a path if they don’t exist—no need to chain mkdir -p commands. For example, install -d ${D}/usr/local/bin will create /usr, /usr/local, and /usr/local/bin in one go if they’re missing.
• Atomic file replacement: When copying a file to an existing location, install replaces the target atomically, ensuring the file is never in a half-written state. This is way more reliable than cp followed by chmod, which leaves a window where the file might be accessible with incorrect permissions.
• Built-in ownership control: You can use the -o and -g flags to set the file/directory owner and group directly (e.g., install -o root -g root myfile ${D}/bin). With cp or mkdir, you’d need a separate chown command to do the same.
• Idempotent behavior: Running install multiple times won’t cause errors. If the target file already exists, it just replaces it; if the directory is already there, install -d does nothing. This makes your do_install task more robust, especially if it’s re-run during incremental builds.

Breaking Down Your Example do_install Task #

Let’s walk through each line of your sample code to unpack what’s happening:

do_install () {
    autotools_do_install
    install -d ${D}${base_bindir}
    mv ${D}${bindir}/sed ${D}${base_bindir}/sed
    rmdir ${D}${bindir}/
}

1. autotools_do_install: This is a Yocto helper function for autotools-based projects (like sed). It runs make install under the hood, which installs the compiled binary to the default location—here, that’s ${D}${bindir}, which translates to something like tmp/work/.../rootfs/usr/bin (since ${bindir} is typically /usr/bin).
2. install -d ${D}${base_bindir}: Creates the base binary directory in the target root filesystem. ${base_bindir} is Yocto’s variable for /bin, so this line ensures /bin exists in the final rootfs (it might not be created by autotools_do_install if the project defaults to /usr/bin).
3. mv ${D}${bindir}/sed ${D}${base_bindir}/sed: Moves the sed binary from /usr/bin to /bin. This is often done because /bin is part of the early root filesystem (mounted before /usr in some boot setups), so having critical tools like sed there ensures they’re available during early boot stages.
4. rmdir ${D}${bindir}/: Cleans up the now-empty /usr/bin directory. Since we moved sed out, this directory has no files left, so we remove it to avoid cluttering the rootfs with empty directories.

内容的提问来源于stack exchange，提问作者md.jamal