[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Pan-users] [ANNOUNCE] Pan release 0.152
Re: [Pan-users] [ANNOUNCE] Pan release 0.152
Thu, 17 Nov 2022 04:54:30 -0000 (UTC)
Pan/0.153 (Mariupol; 6dc70f18f)
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 <firstname.lastname@example.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
[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, 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.
 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] [ANNOUNCE] Pan release 0.153, Dominique Dumont, 2022/11/13