This means you could do the following as an alternative way of re-creating the Slackware provided “/usr/local” sub-directory structure.

I forgot I once extended this idea and created a little shell script I called f2sb ("Forgot 2 SlackBuild"). It can make a Slackware package out of your manually installed package by finding all the files using change timestamps in a range governed by a reference file from within the package.

You provide it options like so:

For example, say I installed Zstandard version 1.4.3 manually via `make install`. Then at any time in the future, I could simply issue the following (as root):

and it would produce "/tmp/zstd-1.4.3-x86_64-1.tgz" (assuming a 64bit system). This would allow me to (re)install it on top via installpkg and have it tracked alongside all other packages, which also simplifies removal should I ever need that.

1 members found this post helpful.

You could try my little example script against one of the files from one of the packages you make installed into /usr/local and see if it accurately finds all the sibling files from the package in question. It is still a nice way of listing files in a package, even if you don't personally need it.

Just tried f2sb.sh on unbound and it worked just fine, got all the files that were part of the unbound package - compared the package your script generated with the one I created when I compiled it.
I used to make && make install back in the day and then archive the whole compilation directory, but moved to creating packages, it's cleaner & more efficient.
Saved your little script in my /kit/tools directory for when/if I'll need it. Thanks!

1 members found this post helpful.

Thanks for checking it. I have used these tricks quite a bit but always interesting to hear that it actually works for someone else!

If you have some app to compile - just tell us. Such general discussion is not much of worth without working example. First of all developer usually provides information about how to install. So this is the first point to start with.

@igadoter

OP already opened a thread for a specific app:
https://www.linuxquestions.org/quest...er-4175662129/

I'm probably being too literal minded here, but for people not knowledgeable about Unix this statement is misleading. Perhaps you meant they have some similar syntax and use snippets in their target recipes that are sequences of shell commands, so learning about Makefiles may feel similar to learning about shell. Or maybe you meant that you can take the commands out of the recipes and put them in shell scripts.

But a Makefile is a very different beast than a shell script. First there are key syntax differences that will trip you up if you're writing a Makefile thinking of it as a shell script, e.g. $(dmesg) means something entirely different as a Makefile macro than it does as a shell expression. More fundamentally, a Makefile is processed in two passes, one that reads all the directives, variable definitions, and rules followed by a second one that picks a rule and recursively processes each rule needed to satisfy prerequisites down a chain leading back down to the starting rule, followed by processing of that rule itself. Shell scripts run in one pass top to bottom.

The OP needs to be more specific. The only true portable version I understand is statically linked application. And then reconfigure Geany to look for plugins in specified folder. The other solution is Docker. Maybe Geany already has a Docker container. But I confess I failed miserably trying to build Docker myself.

Edit: putting binaries into user home directory is just how Unix worked, common users were not allowed to install system-wide, for custom builds $HOME is place to put binaries.