when building extension, workaround for when DESTDIR fails

[GNUser]

When building extensions, a very handy trick the DESTDIR=/tmp/dest argument to make install (where /tmp/dest is simply an empty directory).

Rarely, DESTDIR doesn't work, which can make it difficult to build an extension.

The wiki gives a workaround for when DESTDIR fails here, but the workaround has a caveat (see the "Be careful..." part), which requires its own workaround.

I recently discovered a little utility called inotifywait (part of the inotify-tools.tcz extension) which provides a much cleaner workaround for when DESTDIR fails:

Code: [Select]

$ inotifywait --quiet --monitor --recursive -e create --format '%w%f' /usr/local >new.txt &
-> install the package (e.g., sudo make install, sudo cmake --install build, etc.)
$ pkill inotifywait
$ cat new.txt | sort | uniq >list.txt
$ tar -cvf dest.tar -T list.txt
$ mkdir /tmp/dest
$ tar -xvf dest.tar -C /tmp/dest

After the above, /tmp/dest will contain exactly what you would expect

P.S. Regarding some of the options to inotifywait: The tool is quite chatty by default. The --quiet flag tells it not to introduce itself when it starts running. The -e create option quiets it down further by telling it that we are only interested in new directories and files, nothing else. The --format '%w%f' option quiets it down more by saying that we want it to merely output the path of new directories and files, without any commentary. Even after all this there are still some duplicate lines in the output, which is why the sort | uniq step is needed later on.

P.P.S. I would add this tip the appropriate place in the wiki, but the wiki will not allow me to log in no matter what I do.

[Rich]

Hi GNUser

... Rarely, DESTDIR doesn't work, which can make it difficult to build an extension. ...

When building an extension I really prefer the build system not install files in the system
directories, but this looked like a good technique so I decided to adapt it and skip DESTDIR.

This is what I did:

Code: [Select]

PROGRAMPACKAGE="/home/$USER/pkg/"

# This creates a list of files added to /usr/local by sudo make install.
inotifywait --quiet --monitor --recursive -e create --format '%w%f' /usr/local > list.txt &

# Install program to /usr/local.
sudo make install

pkill inotifywait

# This sorts the file in place while removing duplicate entries.
echo "$(sort -u list.txt)" > list.txt

while read -r ENTRY
do
# Keep file entries, skip entries that are only paths.
if [ -f "$ENTRY" ]
then
echo "$ENTRY" >> files.txt
# since we found a file, we want its path.
echo "${ENTRY%/*}" >> paths.txt
fi
done < list.txt

# This sorts the file in place while removing duplicate entries.
echo "$(sort -u paths.txt)" > paths.txt

# Create the directory tree to move the installed files to.
while read -r ENTRY
do
mkdir -p "$PROGRAMPACKAGE$ENTRY"
done < paths.txt

# Move the files from my system to the package directories where they belong.
while read -r ENTRY
do
sudo mv "$ENTRY" "$PROGRAMPACKAGE$ENTRY"
done < files.txt

# Change ownership so I don't need sudo for any further changes.
sudo chown -R tc:staff "$PROGRAMPACKAGE"
I parse the list inotifywait creates and keep the entries that point to files.
For every entry that points to a file, I strip the file name and save the path.
I use the saved paths to create a directory tree in my package directory.
Then I move the files to my package directory.

[Paul_123]

That's a neat option Rich.  The alternative way of just setting a timestamp mark   (touch /tmp/mark) fails quite often, as some installers keep the original modification dates that are in the source package.

[GNUser]

Interesting. So you are manually creating the package subdirectories rather than letting  tar  handle it for you. Then moving the files from system directory to the package directory.

The approach in my original post (installing files to the system then using tar to collect inotifywait's log) requires a reboot to clean up the system directories. Your idea of moving the files to the package directory is nice, as it obviates the need for a reboot to clean up the system directories.

[Rich]

Hi Paul_123

That's a neat option Rich. ...

Thanks, "neat" is what I was shooting for. 

[Rich]

Hi GNUser

Interesting. So you are manually creating the package subdirectories rather than letting  tar  handle it for you. ...

Yeah, I felt it was safest to first test each entry pointed to an actual file to move, My concern was
if an entry pointing to a directory made it into the list. Wouldn't want to move /usr/local/lib. 

Once I have an entry pointing to an actual file, I also have a path I need to create.

Even if I used tar, I still need to (carefully) get rid of the installed files either by rebooting (yuck) or
parsing a list of things to delete.

[Paul_123]

I have inotify-tools built now for piCore14.  Updated my first script to use this.  Worked great.

[Rich]

Hi Paul_123
I'm wondering if it might make sense to monitor  /usr  instead of  /usr/local  for
programs that insist on hard coding paths like  /usr/bin  or  /usr/lib.
Maybe also  /etc  for programs that want to place config files there, something like this:

Code: [Select]

inotifywait --quiet --monitor --recursive -e create --format '%w%f' /usr /etc > list.txt &

[Paul_123]

Well since I just did bluez.  It installs a file in /lib/udev

So I just added a second location to watch.