Re: [Pan-users] [ANNOUNCE] Pan release 0.152

[Duncan]

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