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.
Related
I'm really lost on how to actually use multiple files in Coq. I was trying to follow these directions.
I have two files.
src/a.v:
Definition bar: nat := 1.
src/b.v:
Require Import a.
Definition foo := bar.
I attempt to compile as such:
coqc -R src "" src/a.v src/b.v
I get the following error:
user#machine:~/code/coq$ coqc -R src "" src/a.v src/b.v
While loading initial state:
Loading file /home/user/code/coq/src/.b.aux: aux file name mismatch
I can't find any clear information on how you actually compile with multiple files
I recommend you perform two calls to coqc, first with a then with b. Having multiple files in the argument command line is actually not supported [we will improve the interface in next versions as to warn about this]
In the book "Embedded Linux Systems with the Yocto Project", Chapter 4 contains a sample called "HelloWorld - BitBake style". I encountered a bunch of problems trying to get the old example working against the "Sumo" release 2.5.
If you're like me, the first error you encountered following the book's instructions was that you copied across bitbake.conf and got:
ERROR: ParseError at /tmp/bbhello/conf/bitbake.conf:749: Could not include required file conf/abi_version.conf
And after copying over abi_version.conf as well, you kept finding more and more cross-connected files that needed to be moved, and then some relative-path errors after that... Is there a better way?
Here's a series of steps which can allow you to bitbake nano based on the book's instructions.
Unless otherwise specified, these samples and instructions are all based on the online copy of the book's code-samples. While convenient for copy-pasting, the online resource is not totally consistent with the printed copy, and contains at least one extra bug.
Initial workspace setup
This guide assumes that you're working with Yocto release 2.5 ("sumo"), installed into /tmp/poky, and that the build environment will go into /tmp/bbhello. If you don't the Poky tools+libraries already, the easiest way is to clone it with:
$ git clone -b sumo git://git.yoctoproject.org/poky.git /tmp/poky
Then you can initialize the workspace with:
$ source /tmp/poky/oe-init-build-env /tmp/bbhello/
If you start a new terminal window, you'll need to repeat the previous command which will get get your shell environment set up again, but it should not replace any of the files created inside the workspace from the first time.
Wiring up the defaults
The oe-init-build-env script should have just created these files for you:
bbhello/conf/local.conf
bbhello/conf/templateconf.cfg
bbhello/conf/bblayers.conf
Keep these, they supersede some of the book-instructions, meaning that you should not create or have the files:
bbhello/classes/base.bbclass
bbhello/conf/bitbake.conf
Similarly, do not overwrite bbhello/conf/bblayers.conf with the book's sample. Instead, edit it to add a single line pointing to your own meta-hello folder, ex:
BBLAYERS ?= " \
${TOPDIR}/meta-hello \
/tmp/poky/meta \
/tmp/poky/meta-poky \
/tmp/poky/meta-yocto-bsp \
"
Creating the layer and recipe
Go ahead and create the following files from the book-samples:
meta-hello/conf/layer.conf
meta-hello/recipes-editor/nano/nano.bb
We'll edit these files gradually as we hit errors.
Can't find recipe error
The error:
ERROR: BBFILE_PATTERN_hello not defined
It is caused by the book-website's bbhello/meta-hello/conf/layer.conf being internally inconsistent. It uses the collection-name "hello" but on the next two lines uses _test suffixes. Just change them to _hello to match:
# Set layer search pattern and priority
BBFILE_COLLECTIONS += "hello"
BBFILE_PATTERN_hello := "^${LAYERDIR}/"
BBFILE_PRIORITY_hello = "5"
Interestingly, this error is not present in the printed copy of the book.
No license error
The error:
ERROR: /tmp/bbhello/meta-hello/recipes-editor/nano/nano.bb: This recipe does not have the LICENSE field set (nano)
ERROR: Failed to parse recipe: /tmp/bbhello/meta-hello/recipes-editor/nano/nano.bb
Can be fixed by adding a license setting with one of the values that bitbake recognizes. In this case, add a line onto nano.bb of:
LICENSE="GPLv3"
Recipe parse error
ERROR: ExpansionError during parsing /tmp/bbhello/meta-hello/recipes-editor/nano/nano.bb
[...]
bb.data_smart.ExpansionError: Failure expanding variable PV_MAJOR, expression was ${#bb.data.getVar('PV',d,1).split('.')[0]} which triggered exception AttributeError: module 'bb.data' has no attribute 'getVar'
This is fixed by updating the special python commands being used in the recipe, because #bb.data was deprecated and is now removed. Instead, replace it with #d, ex:
PV_MAJOR = "${#d.getVar('PV',d,1).split('.')[0]}"
PV_MINOR = "${#d.getVar('PV',d,1).split('.')[1]}"
License checksum failure
ERROR: nano-2.2.6-r0 do_populate_lic: QA Issue: nano: Recipe file fetches files and does not have license file information (LIC_FILES_CHKSUM) [license-checksum]
This can be fixed by adding a directive to the recipe telling it what license-info-containing file to grab, and what checksum we expect it to have.
We can follow the way the recipe generates the SRC_URI, and modify it slightly to point at the COPYING file in the same web-directory. Add this line to nano.bb:
LIC_FILES_CHKSUM = "${SITE}/v${PV_MAJOR}.${PV_MINOR}/COPYING;md5=f27defe1e96c2e1ecd4e0c9be8967949"
The MD5 checksum in this case came from manually downloading and inspecting the matching file.
Done!
Now bitbake nano ought to work, and when it is complete you should see it built nano:
/tmp/bbhello $ find ./tmp/deploy/ -name "*nano*.rpm*"
./tmp/deploy/rpm/i586/nano-dbg-2.2.6-r0.i586.rpm
./tmp/deploy/rpm/i586/nano-dev-2.2.6-r0.i586.rpm
I have recently worked on that hands-on hello world project. As far as I am concerned, I think that the source code in the book contains some bugs. Below there is a list of suggested fixes:
Inheriting native class
In fact, when you build with bitbake that you got from poky, it builds only for the target, unless you mention in your recipe that you are building for the host machine (native). You can do the latter by adding this line at the end of your recipe:
inherit native
Adding license information
It is worth mentioning that the variable LICENSE is important to be set in any recipe, otherwise bitbake rises an error. In our case, we try to build the version 2.2.6 of the nano editor, its current license is GPLv3, hence it should be mentioned as follow:
LICENSE = "GPLv3"
Using os.system calls
As the book states, you cannot dereference metadata directly from a python function. Which means it is mandatory to access metadata through the d dictionary. Bellow, there is a suggestion for the do_unpack python function, you can use its concept to code the next tasks (do_configure, do_compile):
python do_unpack() {
workdir = d.getVar("WORKDIR", True)
dl_dir = d.getVar("DL_DIR", True)
p = d.getVar("P", True)
tarball_name = os.path.join(dl_dir, p+".tar.gz")
bb.plain("Unpacking tarball")
os.system("tar -x -C " + workdir + " -f " + tarball_name)
bb.plain("tarball unpacked successfully")
}
Launching the nano editor
After successfully building your nano editor package, you can find your nano executable in the following directory in case you are using Ubuntu (arch x86_64):
./tmp/work/x86_64-linux/nano/2.2.6-r0/src/nano
Should you have any comments or questions, Don't hesitate !
I've seen that I can use this command in order to copy a directory using cmake:
file(COPY "myDir" DESTINATION "myDestination")
(from this post)
My problem is that I don't want to copy all of myDir, but only the .h files that are in there. I've tried with
file(COPY "myDir/*.h" DESTINATION "myDestination")
but I obtain the following error:
CMake Error at CMakeLists.txt:23 (file):
file COPY cannot find
"/full/path/to/myDIR/*.h".
How can I filter the files that I want to copy to a destination folder?
I've found the solution by myself:
file(GLOB MY_PUBLIC_HEADERS
"myDir/*.h"
)
file(COPY ${MY_PUBLIC_HEADERS} DESTINATION myDestination)
this also works for me:
install(DIRECTORY "myDir/"
DESTINATION "myDestination"
FILES_MATCHING PATTERN "*.h" )
The alternative approach provided by jepessen does not take into account the fact that sometimes the number of files to be copied is too high. I encountered the issue when doing such thing (more than 110 files)
Due to a limitation on Windows on the number of characters (2047 or 8191) in a single command line, this approach may randomly fail depending on the number of headers that are in the folder. More info here https://support.microsoft.com/en-gb/help/830473/command-prompt-cmd-exe-command-line-string-limitation
Here is my solution:
file(GLOB MY_HEADERS myDir/*.h)
foreach(CurrentHeaderFile IN LISTS MY_HEADERS)
add_custom_command(
TARGET MyTarget PRE_BUILD
COMMAND ${CMAKE_COMMAND} -E copy_if_different ${CurrentHeaderFile} ${myDestination}
COMMENT "Copying header: ${CurrentHeaderFile}")
endforeach()
This works like a charm on MacOS. However, if you have another target that depends on MyTarget and needs to use these headers, you may have some compile errors due to not found includes on Windows. Therefore you may want to prefer the following option that defines an intermediate target.
function (CopyFile ORIGINAL_TARGET FILE_PATH COPY_OUTPUT_DIRECTORY)
# Copy to the disk at build time so that when the header file changes, it is detected by the build system.
set(input ${FILE_PATH})
get_filename_component(file_name ${FILE_PATH} NAME)
set(output ${COPY_OUTPUT_DIRECTORY}/${file_name})
set(copyTarget ${ORIGINAL_TARGET}-${file_name})
add_custom_target(${copyTarget} DEPENDS ${output})
add_dependencies(${ORIGINAL_TARGET} ${copyTarget})
add_custom_command(
DEPENDS ${input}
OUTPUT ${output}
COMMAND ${CMAKE_COMMAND} -E copy_if_different ${input} ${output}
COMMENT "Copying file to ${output}."
)
endfunction ()
foreach(HeaderFile IN LISTS MY_HEADERS)
CopyFile(MyTarget ${HeaderFile} ${myDestination})
endforeach()
The downside indeed is that you end up with multiple target (one per copied file) but they should all end up together (alphabetically) since they start with the same prefix ORIGINAL_TARGET -> "MyTarget"
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
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.