Zen

Source string Source string

467/10000 · 467

The string is read only.

English Actions
%{!?tcl_version: %global tcl_version %(echo 'puts $tcl_version' | tclsh)}
%{!?tcl_sitelib: %global tcl_sitelib %{_datadir}/tcl%{tcl_version}}
In order for the macros to work, the package must also `+BuildRequires: tcl+` either directly, or indirectly with `+BuildRequires: tcl-devel+`
Merely adding the `+%{tcl_sitearch}+` and `+%{tcl_sitelib}+` is not enough to ensure that the packages get installed into the correct location. Most Tcl extensions will install into `+%{_libdir}+` by default. There are two ways to change this. For most `+noarch+` packages, you can use the `+--libdir+` and `+--datadir+` configure switches to change the installation directory:
%configure --libdir=%{tcl_sitelib} --datadir=%{tcl_sitelib}
For `+noarch+` packages that aren't fixed by using `+--libdir+`, you can simply move the installation directory in the `+%install+` section of the spec file.
%install
rm -rf $RPM_BUILD_ROOT
make install DESTDIR=$RPM_BUILD_ROOT
install -d $RPM_BUILD_ROOT%{tcl_sitelib}
mv $RPM_BUILD_ROOT%{_datadir}/foobar%{version} $RPM_BUILD_ROOT%{tcl_sitelib}/foobar%{version}
It may also be acceptable to patch upstream's `+configure+` script and `+Makefile+` to add additional flexibility for the install directory, but the packager is not required to do this.
arch-specific packages
%{!?tcl_version: %global tcl_version %(echo 'puts $tcl_version' | tclsh)}
%{!?tcl_sitearch: %global tcl_sitearch %{_libdir}/tcl%{tcl_version}}
While `+%{tcl_sitearch}+` is a symlink to `+%{tcl_sitelib}+` in Fedora 8 and earlier, in Fedora 9 it is an actual directory.
The `+--libdir+` flag for the configure script can often be used to set the correct installation directory:
%build
%configure --libdir=%{tcl_sitearch}
For most arch-specific packages, the `+--libdir+` flag for the configure script is also used to locate tclConfig.sh. Some of these arch-specific packages will break if `+--libdir+` is redirected to `+%{tcl_sitearch}+`. For packages that can't handle alternate values for `+--libdir+`, you can simply move the installation directory in the `+%install+` section of the spec file:
%install
make install DESTDIR=$RPM_BUILD_ROOT
install -d $RPM_BUILD_ROOT%{tcl_sitearch}
mv $RPM_BUILD_ROOT%{_libdir}/foobar%{version} $RPM_BUILD_ROOT%{tcl_sitearch}/foobar%{version}
Arch-specific packages can be generally grouped into three categories: those that provide a shell, those that provide a fooConfig.sh file and a shared library for linking, and those that only provide a shared library for dlopen().
*No shells:*
Very few Tcl extension packages provide a shell. Providing a shell for an extension is frowned upon. The extension's shared library can be dynamically loaded into a Tcl interpreter through the standard `+package require ...+` mechanism without providing a shell that automatically loads the shared library. The exceptions to this rule are the shells that are commonly expected to be present on a system, including Tk (wish) and Expect (expect, expectk).
*-devel subpackage for fooConfig.sh:*
Some arch-specific Tcl extensions provide a shared library and a corresponding `+fooConfig.sh+` file with instructions for linking against the library. The shared library for such packages *must* be installed into %\{_libdir} so that it can be found at runtime by applications that link against it. Unfortunately, the pkgIndex.tcl file in the package directory often references the shared library with a relative path. There are two ways to fix this. First, the maintainer can choose to keep the installation directory as %\{_libdir}, and make a symlink to %\{tcl_sitearch}. Second, the maintainer can choose to patch the pkgIndex.tcl file to contain an appropriate path to the shared library. Either solution is acceptible.
`+fooConfig.sh+` files must be placed in a -devel subpackage. This may require some sed magic to modify `+fooConfig.sh+` so that the paths to the libraries and headers are still correct.
*No dlopen()'d libraries in %\{_libdir}:*
If the extension does *not* provide a `+fooConfig.sh+` file, then the shared library *must not* be installed directly in `+%{_libdir}+`, but in the package-specific installation directory in `+%{tcl_sitearch}+` instead. This may require a patch to update the extension's `+pkgIndex.tcl+` file to look for the shared library in the correct location.
*Stubs are ok if put in -devel subpackage:*
Some Tcl extensions provide a static 'stub' library. Stub libraries are a Tcl-ism to provide version-independent dynamic linking on a variety of platforms. These are not normal static libraries that provide the library's actual functionality, but instead provide a level of indirection pointing to the shared library. These stub libraries do not have the same static linking issues that are generally frowned upon in Fedora, and thus are acceptable. If a package provides such a stub library, it must be placed in a -devel subpackage. More information on stubs can be found on the Tcl wiki: https://wiki.tcl-lang.org/page/Stubs

Loading…

User avatar None

Source string added
*No shells:*
Very few Tcl extension packages provide a shell. Providing a shell for an extension is frowned upon. The extension's shared library can be dynamically loaded into a Tcl interpreter through the standard `+package require ...+` mechanism without providing a shell that automatically loads the shared library. The exceptions to this rule are the shells that are commonly expected to be present on a system, including Tk (wish) and Expect (expect, expectk).
4 years ago
Browse all string changes

Things to check

Ellipsis

The string uses three dots (...) instead of an ellipsis character (…)

Reset

Glossary

English English
No related strings found in the glossary.

1009903 String information

Source string description
type: Plain text
Flags
no-wrap, read-only
Source string location
./pages/Tcl.adoc:119
String age
4 years ago
Last updated
a year ago
Source string age
4 years ago
Translation file
pot/master/pages/Tcl.pot, string 38