Brian Morrison posted on Wed, 16 Nov 2022 15:29:26 +0000 as excerpted: > On Wed, 16 Nov 2022 13:09:04 -0000 (UTC) > Maurice via Pan-users <pan-users@nongnu.org> wrote: > >> On Sun, 13 Nov 2022 20:11:37 +0000, Brian Morrison wrote: >> >> > ./autogen.sh --prefix=/usr >> >> Well, I couldn't get hold of autogen.sh, Brian, but many thanks >> for your info. Will reyurn to the fray soon. > > autogen.sh is in the pan tarball that you download, along with > configure.ac
[Some general search-path and build-system background for those who might find it useful...] Yes. And to the point, the ./ prefix indicates a path relative to the current directory[1], so any time you see the ./ prefix in the context of build instructions, it strongly indicates running either an executable shipped in the tarball itself, or something you just built from that tarball (say for testing without actually installing it to the system). Of course that implies that you've already untarred the tarball and entered the resulting directory, a common enough procedure that sometimes build instructions skip right to the "run ..." bit, but in this case that was explicit in the instructions as well. > Running autogen.sh creates the configure program that when re-run during > the rpmbuild process sets up the Fedora configuration for the final > binary rpms. Yes. The general toolset that both autogen and the configure scripts are part of is GNU autotools. It's one of the older and more common methods of allowing an upstream to create a portable configuration and build bootstrapping system usable across many distros and OSs, including but not limited to Linux, the BSDs and other Unices (including Sun's Solaris and Apple's OSX), and MS Windows, among others, tho of course not every package using autotools supports all platforms autotools itself does. CMake is another very common more modern alternative used by a lot of stuff these days. The rpm/deb/other-package-manager stuff builds on top of that, automating dependency and installed-files tracking. --- [1] Current directory, aka current working directory: Instead of searching for the executable using directories in the existing PATH variable, the normal unprefixed method of finding the named executable in the normal system and user executable directories like the system's /usr/bin and often ~/bin (aka $HOME/bin, aka your user's executable directory, if so configured). Unlike many OSs Linux/Unix does not normally include the current working directory in the executable search path by default. A user can of course add the current working directory to the executable search path by changing the PATH variable accordingly, but doing so tends to be discouraged for security reasons -- the idea is that the default search path should only contain deliberately installed user or distro vetted executables, *not* whatever random executable happens to exist by that name in whatever directory you're currently working in. Of course it's always possible to run executables in the current directory if that's what you specifically intend (as here) using the ./ prefix, just as it's always possible to run a specific executable using an absolute path by prefixing it with /<whatever-path>. The idea is that if you want a specific executable you always prefix the path, whereas if you want whatever user or system executable happens to appear first in the directories listed in PATH, you don't have to specify path. (In fact, the fact that default path search order is that specified in the PATH variable is often deliberately used to allow "wrapper scripts" that do some setup before calling the normal executable. For instance, I have a pan wrapper script that exploits the fact that pan uses the PAN_HOME environmental variable if set to look for its configuration and data files, to allow me to run separate pan instances for binary groups, text groups, and testing, with text being my default instance. So if I simply run "pan", it finds the "pan" wrapper script in ~/bin first, since that appears first in my PATH, and runs the default text instance, setting up stuff accordingly for that before the script then calls "/usr/bin/pan" specifically, using the absolute path so as to avoid the script calling itself as would happen if it just called "pan"!) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman _______________________________________________ Pan-users mailing list Pan-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-users
