Question mark and exclamation point syntax in srpm spec file - centos

I'm trying to understand how the Postgres 9.1 rpms are built on CentOS/RHEL 6, so I'm taking a look at the spec file from the source rpms.
What does the following syntax do/mean? Specifically, the question mark and exclamation point?
%{!?test:%define test 1}
%{!?plpython:%define plpython 1}
%{!?pltcl:%define pltcl 1}
%{!?plperl:%define plperl 1}
%{!?ssl:%define ssl 1}
%{!?intdatetimes:%define intdatetimes 1}
%{!?kerberos:%define kerberos 1}
%{!?nls:%define nls 1}
%{!?xml:%define xml 1}
%{!?pam:%define pam 1}
%{!?disablepgfts:%define disablepgfts 0}
%{!?runselftest:%define runselftest 0}
%{!?uuid:%define uuid 1}
%{!?ldap:%define ldap 1
I understand you can define a macro variable with %define <name>[(opts)] <value>, and I believe the exclamation mark is a logical negation operator. I can't find any info on the question mark or examples like the above though. Seems like some sort of test before defining the macro variable.
Here is a paste of the spec file.

Lets review a single item here:
%{!?plpython:%define plpython 1}
On line 102 we also see this:
%if %plpython
BuildRequires: python-devel
%endif
As you said, we know that this is a macro, that can also be confirmed via the Fedora docs. Now if we expand on our search into the Fedora documentation we find conditional macros. This states the following:
You can use a special syntax to test for the existence of macros. For example:
%{?macro_to_test: expression}
This syntax tells RPM to expand the expression if macro_to_test exists, otherwise ignore. A leading exclamation point, !, tests for the non-existence of a macro:
%{!?macro_to_test: expression}
In this example, if the macro_to_test macro does not exist, then expand the expression.
The Fedora docs have provided the answer, if the plpython macro doesn't exist, then
%define plython 1
If you look at line 38 you can also see this:
# In this file you can find the default build package list macros. These can be overridden by defining
# on the rpm command line:
# rpm --define 'packagename 1' .... to force the package to build.
# rpm --define 'packagename 0' .... to force the package NOT to build.
# The base package, the lib package, the devel package, and the server package always get built.
So if you don't define the the macro when you build the package (I imagine this is what most users would do) it's going to ensure that the buildrequires are properly configured for what appears to be a standard PostgreSQL installation.

Related

Configure ac code fails to detect libXI presence

I am currently executing the configure script of gtk. It tests for the presence of XInput, and it stops the execution with the error message:"configure: error: *** XInput2 extension not found. Check 'config.log' for more details.
Looking at config.log, it says "configure:23050: error: *** XInput2 extension not found. Check 'config.log' for more details."
So, the same except for the line number.
Then I decided to look at configure.ac. There I found the full Xi detection test that it is:
if $PKG_CONFIG --exists "xi" ; then
X_PACKAGES="$X_PACKAGES xi"
GTK_PACKAGES_FOR_X="$GTK_PACKAGES_FOR_X xi"
AC_CHECK_HEADER(X11/extensions/XInput2.h,
have_xinput2=yes
AC_DEFINE(XINPUT_2, 1, [Define to 1 if XInput 2.0 is available]))
gtk_save_LIBS="$LIBS"
LIBS="$LIBS -lXi"
# Note that we also check that the XIScrollClassInfo struct is defined,
# because at least Ubuntu Oneiric seems to have XIAllowTouchEvents(), but not the XIScrollClassInfo struct.
AC_CHECK_FUNC([XIAllowTouchEvents],
[AC_CHECK_MEMBER([XIScrollClassInfo.number],
have_xinput2_2=yes
AC_DEFINE(XINPUT_2_2, 1, [Define to 1 if XInput 2.2 is available]),
have_xinput2_2=no,
[[#include <X11/extensions/XInput2.h>]])])
LIBS="$gtk_save_LIBS"
if test "x$have_xinput2_2" = "xyes"; then
X_EXTENSIONS="$X_EXTENSIONS XI2.2"
else
X_EXTENSIONS="$X_EXTENSIONS XI2"
fi
fi
AS_IF([test "x$have_xinput2" != "xyes"],
[AC_MSG_ERROR([*** XInput2 extension not found. Check 'config.log' for more details.])])
I am no expert about setting configure.ac, but I thought that this line: "if $PKG_CONFIG --exists "xi" ; then" would be satisfied by this parameter that I pass to configure:
PKG_CONFIG_PATH=:/media/34GB/Arquivos-de-Programas-Linux/xorg/Xi-1.5.0/lib/pkgconfig/
Also this line:
AC_CHECK_HEADER(X11/extensions/XInput2.h,
have_xinput2=yes
AC_DEFINE(XINPUT_2, 1, [Define to 1 if XInput 2.0 is available]))
could not have been satisfied by this parameter that I pass to configure?
CPPFLAGS=-I/media/34GB/Arquivos-de-Programas-Linux/xorg/Xi-1.5.0/include/
I am a bit lost as to why it doesn't detect nothing.
A curious point that I read in the documentation is that there is a parameter called: --disable-xinput.
Well I am passing it to configure and it obviously didn't disable the test. So I would appreciate any suggestions about how to change the test to try to figure out what is wrong with it (or with my system)
Solution found
If I replace:
if $PKG_CONFIG --exists "xi" ; then
on configure.ac, by:
if $PKG_CONFIG --print-errors --exists "xi" ; then
and then execute autoconf, it will generate a new configure based on this "new" configure.ac that will print all the required libraries that should be passed to configure.
First it was the .pc file of libXi, then the pc. file of Inputproto (that I had to download and install) an so on. I also really had to add libXi's include dir to CPPFLAGS, so it could find XInput2.h.
My final configure command was:
LD_LIBRARY_PATH=/media/34GB/Arquivos-de-Programas-Linux/Glib-2.41.2/lib/ CPPFLAGS="-I/media/34GB/Arquivos-de-Programas-Linux/xorg/X11-1.4.4/include/ -I/media/34GB/Arquivos-de-Programas-Linux/xorg/Xorgproto-2018.1/include/ -I/media/34GB/Arquivos-de-Programas-Linux/xorg/Xi-1.5.0/include/" LDFLAGS="-L/media/34GB/Arquivos-de-Programas-Linux/xorg/X11-1.4.4/lib/" ./configure --prefix=/media/34GB/Arquivos-de-Programas-Linux/Gtk+-3.4.0 PKG_CONFIG_PATH=/media/34GB/Arquivos-de-Programas-Linux/Glib-2.41.2/lib/pkgconfig/:/media/34GB/Arquivos-de-Programas-Linux/Atk-2.15.4/lib/pkgconfig/:/media/34GB/Arquivos-de-Programas-Linux/Pango-1.30.0/lib/pkgconfig/:/media/34GB/Arquivos-de-Programas-Linux/Cairo-1.10.0/lib/pkgconfig/:/media/34GB/Arquivos-de-Programas-Linux/Gdk-pixbuf-2.30.0/lib/pkgconfig/:/media/34GB/Arquivos-de-Programas-Linux/Pixman-0.18.4/lib/pkgconfig/:/media/34GB/Arquivos-de-Programas-Linux/Fontconfig-2.8.0/lib/pkgconfig/:/media/34GB/Arquivos-de-Programas-Linux/Freetype-2.2.1/lib/pkgconfig/:/media/34GB/Arquivos-de-Programas-Linux/Png-1.2.14/lib/pkgconfig/:/media/34GB/Arquivos-de-Programas-Linux/xorg/Xi-1.5.0/lib/pkgconfig/:/media/34GB/Arquivos-de-Programas-Linux/xorg/Inputproto-1.5.0/lib/pkgconfig/:/media/34GB/Arquivos-de-Programas-Linux/xorg/X11-1.4.4/lib/pkgconfig/:/media/34GB/Arquivos-de-Programas-Linux/xorg/Xorgproto-2018.1/share/pkgconfig/:/media/34GB/Arquivos-de-Programas-Linux/xorg/Xcb-1.4/lib/pkgconfig/:/media/34GB/Arquivos-de-Programas-Linux/xorg/Pthread-stubs-0.1/lib/pkgconfig/:/media/34GB/Arquivos-de-Programas-Linux/xorg/Xau-1.0.0/lib/pkgconfig/:/media/34GB/Arquivos-de-Programas-Linux/xorg/Xext-1.1.1/lib/pkgconfig/

Is there any way to define own options in *.pc files except standard options

I am trying to make a .pc file and want to define a flag ldflags and use it something like this
pkg-config package --ldflags
but it's showing unknown option ldflags.
Is there a way to define my own option in pc file.
.pc file has special format, check here:
The file format contains predefined metadata keywords and freeform
variables.
keywords are fixed, e.g. Cflags and most of them correspond to pkg-config tool options e.g. --cflags. But variables:
... can be used by the keyword definitions for flexibility or to store
data not covered by pkg-config
So, it possible to add own, for example I created minimum possible one (Name, Version, Description are mandatory keywords):
$ cat test.pc
Name: test
Version: 1
Description: test
aaa=bbb
$ pkg-config --variable=aaa
bbb
It's possible to list all with --print-variables option (interestingly though that pcfiledir variable is added automatically):
$ pkg-config --print-variables test.pc
aaa
pcfiledir
$ pkg-config --variable=pcfiledir
.
It can even (re)define one variable using another:
$ cat test.pc
Name: test
Version: 1
Description: test
aaa=bbb${ccc}
$ pkg-config test.pc --variable=aaa --define-variable=ccc=xxx
bbbxxx
Wonder about your use case? since contents of this file is just for keeping metadata about dependencies some package has. Maybe you should add instead these flags to Libs or Libs.private keywords?

Coqtop cannot load file

I'm currently working on Software Foundations – Logical Foundation.
In short, I got error Error: Cannot find a physical path bound to logical path matching suffix <> and prefix LF.
I have Coq brew installed.
I have the following files located at ~/Documents/Notes/PL/SF/LF/
_CoqProject contains single line: -Q . LF
Basics.v contains code for the first chapter
Makefile generated by command coq_makefile -f _CoqProject *.v -o Makefile
Then I make Basics.vo by make Basics.vo
Now I open coqtop, and try to run the command From LF Require Export Basics. and here is what it looks like
╭─~/Documents/Notes/PL/SF/LF
╰─$ coqtop
Welcome to Coq 8.11.0 (January 2020)
Coq < From LF Require Export Basics.
Toplevel input, characters 23-29:
> From LF Require Export Basics.
> ^^^^^^
Error: Cannot find a physical path bound to logical path matching suffix
<> and prefix LF
Here is the output of Print LoadPath.. The last line of the output clearly shows <> /Users/myname/Documents/Notes/PL/SF/LF, for which I don't know what does it mean.
Coq <
Coq < Print LoadPath.
Logical Path / Physical path:
<> /usr/local/Cellar/coq/8.11.0/share/coq
latex /usr/local/Cellar/coq/8.11.0/share/coq/latex
<> /usr/local/Cellar/coq/8.11.0/lib/coq/user-contrib
Ltac2 /usr/local/Cellar/coq/8.11.0/lib/coq/user-contrib/Ltac2
Coq /usr/local/Cellar/coq/8.11.0/lib/coq/plugins
Coq.firstorder /usr/local/Cellar/coq/8.11.0/lib/coq/plugins/firstorder
Coq.ltac /usr/local/Cellar/coq/8.11.0/lib/coq/plugins/ltac
Coq.extraction /usr/local/Cellar/coq/8.11.0/lib/coq/plugins/extraction
Coq.btauto /usr/local/Cellar/coq/8.11.0/lib/coq/plugins/btauto
Coq.syntax /usr/local/Cellar/coq/8.11.0/lib/coq/plugins/syntax
Coq.nsatz /usr/local/Cellar/coq/8.11.0/lib/coq/plugins/nsatz
Coq.omega /usr/local/Cellar/coq/8.11.0/lib/coq/plugins/omega
Coq.cc /usr/local/Cellar/coq/8.11.0/lib/coq/plugins/cc
Coq.derive /usr/local/Cellar/coq/8.11.0/lib/coq/plugins/derive
Coq.ssr /usr/local/Cellar/coq/8.11.0/lib/coq/plugins/ssr
Coq.rtauto /usr/local/Cellar/coq/8.11.0/lib/coq/plugins/rtauto
Coq.micromega /usr/local/Cellar/coq/8.11.0/lib/coq/plugins/micromega
Coq.funind /usr/local/Cellar/coq/8.11.0/lib/coq/plugins/funind
Coq.setoid_ring /usr/local/Cellar/coq/8.11.0/lib/coq/plugins/setoid_ring
Coq.ssrmatching /usr/local/Cellar/coq/8.11.0/lib/coq/plugins/ssrmatching
Coq /usr/local/Cellar/coq/8.11.0/lib/coq/theories
Coq.PArith /usr/local/Cellar/coq/8.11.0/lib/coq/theories/PArith
Coq.MSets /usr/local/Cellar/coq/8.11.0/lib/coq/theories/MSets
Coq.QArith /usr/local/Cellar/coq/8.11.0/lib/coq/theories/QArith
Coq.Sorting /usr/local/Cellar/coq/8.11.0/lib/coq/theories/Sorting
Coq.Program /usr/local/Cellar/coq/8.11.0/lib/coq/theories/Program
Coq.ZArith /usr/local/Cellar/coq/8.11.0/lib/coq/theories/ZArith
Coq.Bool /usr/local/Cellar/coq/8.11.0/lib/coq/theories/Bool
Coq.Sets /usr/local/Cellar/coq/8.11.0/lib/coq/theories/Sets
Coq.NArith /usr/local/Cellar/coq/8.11.0/lib/coq/theories/NArith
Coq.Wellfounded /usr/local/Cellar/coq/8.11.0/lib/coq/theories/Wellfounded
Coq.Arith /usr/local/Cellar/coq/8.11.0/lib/coq/theories/Arith
Coq.Vectors /usr/local/Cellar/coq/8.11.0/lib/coq/theories/Vectors
Coq.Reals /usr/local/Cellar/coq/8.11.0/lib/coq/theories/Reals
Coq.Logic /usr/local/Cellar/coq/8.11.0/lib/coq/theories/Logic
Coq.Floats /usr/local/Cellar/coq/8.11.0/lib/coq/theories/Floats
Coq.Classes /usr/local/Cellar/coq/8.11.0/lib/coq/theories/Classes
Coq.Lists /usr/local/Cellar/coq/8.11.0/lib/coq/theories/Lists
Coq.Relations /usr/local/Cellar/coq/8.11.0/lib/coq/theories/Relations
Coq.Unicode /usr/local/Cellar/coq/8.11.0/lib/coq/theories/Unicode
Coq.Structures /usr/local/Cellar/coq/8.11.0/lib/coq/theories/Structures
Coq.Setoids /usr/local/Cellar/coq/8.11.0/lib/coq/theories/Setoids
Coq.Numbers.Integer.Binary
/usr/local/Cellar/coq/8.11.0/lib/coq/theories/Numbers/Integer/Binary
Coq.Numbers.Integer.NatPairs
/usr/local/Cellar/coq/8.11.0/lib/coq/theories/Numbers/Integer/NatPairs
Coq.Numbers.Integer.Abstract
/usr/local/Cellar/coq/8.11.0/lib/coq/theories/Numbers/Integer/Abstract
Coq.Numbers.Integer
/usr/local/Cellar/coq/8.11.0/lib/coq/theories/Numbers/Integer
Coq.Numbers.NatInt
/usr/local/Cellar/coq/8.11.0/lib/coq/theories/Numbers/NatInt
Coq.Numbers.Natural.Binary
/usr/local/Cellar/coq/8.11.0/lib/coq/theories/Numbers/Natural/Binary
Coq.Numbers.Natural.Peano
/usr/local/Cellar/coq/8.11.0/lib/coq/theories/Numbers/Natural/Peano
Coq.Numbers.Natural.Abstract
/usr/local/Cellar/coq/8.11.0/lib/coq/theories/Numbers/Natural/Abstract
Coq.Numbers.Natural
/usr/local/Cellar/coq/8.11.0/lib/coq/theories/Numbers/Natural
Coq.Numbers.Cyclic.Int63
/usr/local/Cellar/coq/8.11.0/lib/coq/theories/Numbers/Cyclic/Int63
Coq.Numbers.Cyclic.Int31
/usr/local/Cellar/coq/8.11.0/lib/coq/theories/Numbers/Cyclic/Int31
Coq.Numbers.Cyclic.ZModulo
/usr/local/Cellar/coq/8.11.0/lib/coq/theories/Numbers/Cyclic/ZModulo
Coq.Numbers.Cyclic.Abstract
/usr/local/Cellar/coq/8.11.0/lib/coq/theories/Numbers/Cyclic/Abstract
Coq.Numbers.Cyclic
/usr/local/Cellar/coq/8.11.0/lib/coq/theories/Numbers/Cyclic
Coq.Numbers /usr/local/Cellar/coq/8.11.0/lib/coq/theories/Numbers
Coq.Compat /usr/local/Cellar/coq/8.11.0/lib/coq/theories/Compat
Coq.Strings /usr/local/Cellar/coq/8.11.0/lib/coq/theories/Strings
Coq.Init /usr/local/Cellar/coq/8.11.0/lib/coq/theories/Init
Coq.FSets /usr/local/Cellar/coq/8.11.0/lib/coq/theories/FSets
<> /Users/myname/Documents/Notes/PL/SF/LF
Can anyone help me figure out what happened?
You need to associate the current directory (.../LF) to the LF prefix:
(* In coqtop *)
Add LoadPath "." as LF.
(* So that... *)
Print LoadPath.
(* shows:
...
LF /Users/.../LF
*)
I also heard that directly using coqtop is strongly discouraged, and instead it is recommended to use a proper editor (VSCode, Emacs + Proof General, CoqIDE).
I use vscode and vscoq and also face with this problem. It should be mentioned that, if your workspace folder is not directly the lf/ folder downloaded from the webset, you'd better load full path instead of . as LF. (In this situation, it seems that the coqtop cannot see the _Coqproject too.)
A convenient solution is to load full path in the current .v file.
Add LoadPath "D:\path\to\lf\" as LF.

Disable critic for an entire file - Parse::RecDescent precompiled parser & PerlCritic/Tidyall

I'm trying to remove an error from my sanity-checking [when I push code to my git repo, there's a hook that checks the code with perltidy & critic... using tidyall as the handler.]
The specific issue I have is with a pre-compiled Grammar Parser.... and this is not something I want to dive in & fix (sorry - that's outside my comfort zone)
If I add a simple ## no critic to the start of the file, then
perlcritic path/to/class/file.pm
comes back
path/to/class/file.pm source OK
however
tidyall --check-only -r .
comes back with
perlcritic /tmp/Code-TidyAll-Frb0/path/to/class/file.pm failed
exited with 2 - output was:
Unrestricted '## no critic' annotation at line 6, column 1. (Miscellanea::ProhibitUnrestrictedNoCritic, severity 3)
I know I can fix this in the tidyall.ini file:
[PerlCritic lib]
select = **/*.{pm}
ignore = **/class/file.pm
.... however I feel there should be a cleaner solution.
(or, why doesn't tidyall critique the same as critic?)
why doesn't tidyall critique the same as critic?
A simple perlcritic on the command line defaults to severity 5, unless you've configured something different in your ~/.perlcriticrc. The rule ProhibitUnrestrictedNoCritic defaults to severity 3, so your tidyall is running Perl::Critic with at least severity 3. As per its documentation, you can change that via something like this in the tidyall.ini:
[PerlCritic]
argv = -severity 4
And then tidyall's checks should be the same as a perlcritic -4 from the command line. (Unless you've configured custom severity levels in your .perlcriticrc.)
Update: As per your comment, you want to check everything at the "brutal" level. In that case, you can create a perlcriticrc file containing the line [-Miscellanea::ProhibitUnrestrictedNoCritic] which will disable that policy, and then point perlcritic at that file by adding the command-line argument --profile /path/to/custom/perlcriticrc.

Pyinstaller --onefile warning pyconfig.h when importing scipy or scipy.signal

This is very simple to recreate.
If my script foo.py is:
import scipy
Then run:
python pyinstaller.py --onefile foo.py
When I launch foo.exe I get:
WARNING: file already exists but should not: C:\Users\username\AppData\Local\Temp\_MEI86402\Include\pyconfig.h
I've tested a few versions but the latest I've confirmed is 2.1dev-e958e02 running on Win7, Python 2.7.5 (32 bit), Scipy version 0.12.0
I've submitted a ticket with the Pyinstaller folks but haven't heard anything yet. Any clues how to debug this further?
You can hack the spec file to remove the second instance by adding these lines after a=Analysis:
for d in a.datas:
if 'pyconfig' in d[0]:
a.datas.remove(d)
break
The answer by wtobia# worked for me. See https://github.com/pyinstaller/pyinstaller/issues/783
Go to C:\Python27\Lib\site-packages\PyInstaller\build.py
Find the def append(self, tpl): function.
Change if tpl[2] == "BINARY": to if tpl[2] in ["BINARY", "DATA"]:
Expanding upon Ilya's solution, I think this is a little bit more robust solution to modifying the spec file (again place after the a=Analysis... statement).
a.datas = list({tuple(map(str.upper, t)) for t in a.datas})
I only tested this on a small test program (one with a single import and print statement), but it seems to work. a.datas is a list of tuples of strings which contain the pyconfig.h paths. I convert them all to lowercase and then dedup. I actually found that converting all of them all to lowercase was sufficient to get it to work, which suggests to me that pyinstaller does case-sensitive deduping when it should be case-insensitive on Windows. However, I did the deduping myself for good measure.
I realized that the problem is that Windows is case-insensitive and these 2 statements are source directories are "duplicates:
include\pyconfig.h
Include\pyconfig.h
My solution is to manually tweak the .spec file with after the a=Analysis() call:
import platform
if platform.system().find("Windows")>= 0:
a.datas = [i for i in a.datas if i[0].find('Include') < 0]
This worked in my 2 tests.
A more flexible solution would be to check ALL items for case-insensitive collisions.
I ran the archive_viewer.py utility (from PyInstaller) on one of my own --onefile executables that has the same error and found that pyconfig.h is included twice:
(31374007, 6521, 21529, 1, 'x', 'include\\pyconfig.h'),
(31380528, 6521, 21529, 1, 'x', 'Include\\pyconfig.h'),
(31387049, 984, 2102, 1, 'x', 'pytz\\zoneinfo\\CET'),
Sadly though, I don't know how to fix it.
PyInstaller Manual link:
http://www.pyinstaller.org/export/d3398dd79b68901ae1edd761f3fe0f4ff19cfb1a/project/doc/Manual.html#archiveviewer