Closed Radivarig closed 4 years ago
This suggests that some header file accidentally says using namespace opencog
but grapping doesn't find this.
Another possibility: somewhere in a header file there is a namespace opencog {
without a matching }
to close it. The reason for this is this error:
error: 'Type' in namespace 'opencog::opencog'
extern opencog::Type
There's no such thing as namespace opencog::opencog
so the fact that it's doubled is suggesting the root cause.
(Of course, things seem to work fine, for me)
oh wait, I think I know what it is ... I think I've seen it ...
you have to give it time to let the atom-types get build, before saying make -j
to compile the rest.
The atom-types used to be handled correctly as a dependency, but maybe this broke recently.
Correct, it builds with enableParallelBuilding = false
The root cause is that the build of NameServer.o
starts
before the generation of atom_types.h
has finished.
And thus, the closing brace on namespace opencog
has
not yet been written to the header file; without that closing
brace, everything gets confused.
OK, hoping that opencog/atomspace#2448 fixes this
Still the same, I've also tried to build by hand step by step:
unpackPhase && cd source
mkdir build && cd build
cmake $cmakeFlags ..
make -j # same error
cmake flags
-DGUILE_INCLUDE_DIR:PATH=/nix/store/...-guile-2.2.3-dev/include/guile/2.2
-DGMP_INCLUDE_DIR:PATH=/nix/store/...-gmp-6.1.2-dev/include
-DGUILE_SITE_DIR:PATH=share/guile/site
-DPYTHON_DEST:PATH=lib/python3.6/site-packages
-DCXXTEST_BIN_DIR:PATH=/nix/store/...-cxxtest-4.4/bin
-DCPLUS_INCLUDE_PATH:PATH=/nix/store/...-source
OK, clearly my random approach to cmake is failing. Can you try this patch:
--- a/opencog/atoms/atom_types/CMakeLists.txt
+++ b/opencog/atoms/atom_types/CMakeLists.txt
@@ -23,6 +23,7 @@ SET_SOURCE_FILES_PROPERTIES(core_types.pyx PROPERTIES GENERATED TRUE)
INCLUDE_DIRECTORIES(${CMAKE_BINARY_DIR})
ADD_LIBRARY (atom_types
+ atom_types.h
atom_types_init.cc
NameServer.cc
)
Still the same
I'm stuck then. I read 6 or 8 different stackexchange/blog/email threads on this issue, and (as you can verify) the cmakefile has implemented all of the suggestions that they all recommend.
Examining build/opencog/atoms/atom_types/Makefile
, there should have been a line that says
NameServer.cc.o: atom_types.h
so that the complie of NameServer.cc
doesn't start until after atom_types.h
is generated. But I see no such dependency, and cmake doesn't allow me to manually specify it.
Alternately, build/opencog/atoms/atom_types/CMakeFiles/atom_types.dir/build.make
should have listed this dependency... bizarrely, neither file makes any mention at all of atom_types.h
...
Oh wait: it's here: build/opencog/atoms/atom_types/CMakeFiles/atom_types.dir/depend.make
... but that does not seem to trigger the build .... Hmmm.
Changing it to this:
--- a/opencog/atoms/atom_types/NameServer.cc
+++ b/opencog/atoms/atom_types/NameServer.cc
@@ -32,7 +32,8 @@
#include <exception>
#include <opencog/atoms/atom_types/types.h>
-#include <opencog/atoms/atom_types/atom_types.h>
+// #include <opencog/atoms/atom_types/atom_types.h>
+#include "atom_types.h"
#include <opencog/atoms/value/Value.h>
#include <opencog/util/exceptions.h>
produces an error .. which suggests that ... ???
I also tried this:
--- a/opencog/atoms/atom_types/CMakeLists.txt
+++ b/opencog/atoms/atom_types/CMakeLists.txt
@@ -20,7 +20,7 @@ SET_SOURCE_FILES_PROPERTIES(atom_types.inheritance PROPERTIES GENERATED TRUE)
SET_SOURCE_FILES_PROPERTIES(core_types.pyx PROPERTIES GENERATED TRUE)
# The atom_types.h file is written to the build directory
-INCLUDE_DIRECTORIES(${CMAKE_BINARY_DIR})
+INCLUDE_DIRECTORIES(${CMAKE_BINARY_DIR}/opencog/atoms/atom_types)
ADD_LIBRARY (atom_types
atom_types_init.cc
together with
--- a/opencog/atoms/atom_types/NameServer.cc
+++ b/opencog/atoms/atom_types/NameServer.cc
@@ -32,7 +32,8 @@
#include <exception>
#include <opencog/atoms/atom_types/types.h>
-#include <opencog/atoms/atom_types/atom_types.h>
+// #include <opencog/atoms/atom_types/atom_types.h>
+#include "atom_types.h"
#include <opencog/atoms/value/Value.h>
#include <opencog/util/exceptions.h>
but the resulting ./CMakeFiles/atom_types.dir/depend.make
seems to be same as before.
Any chance that an an rm -r build
might fix this? It seems that cmake doesn't always recreate the dependency files; maybe you have an old one sticking around?
When I make -j
, I see this:
-- Atom type name: AttractionLink Attraction
-- Atom type name: ExecutionLink Execution
[ 0%] Built target opencog_atom_types
Scanning dependencies of target atom_types
[ 0%] Building CXX object opencog/atoms/atom_types/CMakeFiles/atom_types.dir/atom_types_init.cc.o
[ 3%] Building CXX object opencog/atoms/atom_types/CMakeFiles/atom_types.dir/NameServer.cc.o
[ 3%] Linking CXX shared library libatom_types.so
[ 3%] Built target atom_types
which suggests that my cmake finished creating atom_types.h
before starting in on NameServer.cc
... but your's says more-or-less the same thing.
Is there a chance that you have a broken atom_types.h
installed somewhere in /usr/include
?
When I start the build with make -j
, cancel it on errors and then start it again with make -j
, the build succeeds.
I found the atom_types.h
in there after the first failed build.
However, the output seems like the one from a non-parallel build.
make -j
[ 0%] Built target SCM_CONFIG
Scanning dependencies of target executioncontext
[ 0%] Built target opencog_atom_types
[ 0%] Built target persist-pg
[ 0%] Building CXX object opencog/cython/opencog/CMakeFiles/logger_cython.dir/logger.cpp.o
[ 0%] Building CXX object opencog/atoms/atom_types/CMakeFiles/atom_types.dir/atom_types_init.cc.o
[ 0%] Building CXX object opencog/atoms/atom_types/CMakeFiles/atom_types.dir/NameServer.cc.o
[ 2%] Cythonizing atomspace.pyx
[ 2%] Built target COPY_TO_LOAD_PATH_IN_BUILD_DIR_FROM__home_radivarig_projects_opencog-dev_source_opencog_atoms_atom_types
[ 2%] Building CXX object opencog/cython/executioncontext/CMakeFiles/executioncontext.dir/Context.cc.o
[ 2%] Built target COPY_TO_LOAD_PATH_IN_BUILD_DIR_FROM__home_radivarig_projects_opencog-dev_source_opencog_sheaf
[ 2%] Built target COPY_TO_LOAD_PATH_IN_BUILD_DIR_FROM__home_radivarig_projects_opencog-dev_source_opencog_matrix
[ 2%] Built target COPY_TO_LOAD_PATH_IN_BUILD_DIR_FROM__home_radivarig_projects_opencog-dev_source_opencog_scm
[ 2%] Built target py_atomspace_header
[ 2%] Linking CXX shared library libexecutioncontext.so
[ 2%] Built target executioncontext
[ 2%] Linking CXX shared library logger.so
[ 2%] Built target logger_cython
[ 2%] Linking CXX shared library libatom_types.so
[ 2%] Built target atom_types
...
atom_types.h
in difference in folders before and after the first build:
λ diff -qr buildFailed/ buildRaw/ Only in buildFailed/CMakeFiles: Progress Only in buildFailed/opencog/atoms/atom_types: atom_types.definitions Only in buildFailed/opencog/atoms/atom_types: atom_types.h Only in buildFailed/opencog/atoms/atom_types: atom_types.inheritance Only in buildFailed/opencog/atoms/atom_types/CMakeFiles/atom_types.dir: CXX.includecache Only in buildFailed/opencog/atoms/atom_types/CMakeFiles/atom_types.dir: depend.internal Files buildFailed/opencog/atoms/atom_types/CMakeFiles/atom_types.dir/depend.make and buildRaw/opencog/atoms/atom_types/CMakeFiles/atom_types.dir/depend.make differ ...
Also there are no /usr/include/
or other shared folders as everything is stored in read-only /nix/store/
so every build I start is done in a sandbox with the same conditions, no leftovers from previous build.
Debugging by hand is almost pure, it is done by my user instead of nix build restricted user, but I get the same output on the first build like in the pure build.
I think that when the compilation of NameServer.cc
starts, the atom_types.h
file is still being written to, and thus is incomplete. If you ctrl-C it, then you only control-C the make, and not the generation of the file, so that, later, by the time you look at it, the atom_types.h
file is finished, complete.
Maybe this fixes it:
--- a/cmake/OpenCogAtomTypes.cmake
+++ b/cmake/OpenCogAtomTypes.cmake
@@ -35,6 +35,8 @@ IF (NOT PYTHON_FILE)
MESSAGE(FATAL_ERROR "OPENCOG_ADD_ATOM_TYPES missing PYTHON_FILE")
ENDIF (NOT PYTHON_FILE)
+FILE(LOCK foo.txt)
+
SET(CNAMES_FILE ${CMAKE_BINARY_DIR}/atom_names.h)
SET(CLASSSERVER_REFERENCE "opencog::nameserver().")
--- a/opencog/atoms/atom_types/CMakeLists.txt
+++ b/opencog/atoms/atom_types/CMakeLists.txt
@@ -22,6 +22,8 @@ SET_SOURCE_FILES_PROPERTIES(core_types.pyx PROPERTIES GENERATED TRUE)
# The atom_types.h file is written to the build directory
INCLUDE_DIRECTORIES(${CMAKE_BINARY_DIR})
+FILE(LOCK foo.txt)
+
ADD_LIBRARY (atom_types
atom_types_init.cc
NameServer.cc
OK, so now I am fully and completely sure that for sure this time for real, without a doubt, that pull req opencog/atomspace#2450 will fix this. Finally.
A different output at least! There is no longer a bunch of output, instead it breaks on a single error:
...
[ 6%] Built target COPY_TO_LOAD_PATH_IN_BUILD_DIR_FROM__build_source_opencog_scm
-- Atom type name: LambdaLink Lambda
-- Atom type name: PutLink Put
-- Atom type name: PatternLink Pattern
-- Atom type name: SatisfyingLink Satisfying
-- Atom type name: GetLink Get
-- Atom type name: QueryLink Query
-- Atom type name: BindLink Bind
-- Atom type name: DualLink Dual
-- Atom type name: EvaluationLink Evaluation
In file included from /build/source/opencog/atoms/value/Value.h:31:0,
from /build/source/opencog/atoms/value/FloatValue.h:27,
from /build/source/opencog/atoms/truthvalue/TruthValue.h:35,
from /build/source/opencog/atomspace/AtomSpace.h:31,
from /build/source/opencog/cython/executioncontext/Context.h:1,
from /build/source/opencog/cython/executioncontext/Context.cc:1:
/build/source/opencog/atoms/atom_types/NameServer.h:34:10: fatal error: opencog/atoms/atom_types/atom_types.h: No such file or directory
#include <opencog/atoms/atom_types/atom_types.h>
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
-- Atom type name: EquivalenceLink Equivalence
make[2]: *** [opencog/cython/executioncontext/CMakeFiles/executioncontext.dir/build.make:63: opencog/cython/executioncontext/CMakeFiles/executioncontext.dir/Context.cc.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:2532: opencog/cython/executioncontext/CMakeFiles/executioncontext.dir/all] Error 2
And I've checked /build/opencog/atoms/atom_types/atom_types.h
does not exist after the error
I give up. See https://stackoverflow.com/questions/59420384/cmake-how-do-i-declare-a-dependency-on-a-generated-header-file maybe someone else will figure it out.
In the meanwhile, as a work-around, try calling make
twice.
or not ... please try again with opencog/atomspace#2450 My latest theory is that a recent python change messed up dependencies (specifically, this one: opencog/atomspace#2420) and maybe that was lurking at the bottom of all the other failures.
Ugh. Now I'm completely sure that was the issue, and its now fixed. This took wayyyy too much effort. All I've got to show for it is that next time, if it ever happens again, the error messages will be a lot more obvious/direct.
Yes, that solves it! This was fun :smile:
fun for who? :smile:
Yeah sorry, well I enjoy to observe your expertise in action. I think it's awesome, regardless of the obstacles part it ends with a solution, so thumbs up from me! Not so happy to see it took much time, I tried to tackle it myself but there are many mysteries for me here, so the best I can do is research one by one and make sure my reports are precise.
I forgot to tag with a smiley-face when I wrote that.
Like all human activities, personal satisfaction during software devel has ups & downs. I like bug-hunting, it's rewarding the way mystery thrillers are. I dislike it, because it's like crossword-puzzles: vaguely enjoyable while you do it, but to what end? It's an activity that puts you "in the zone", in a flow state. But is there something more important to be done, instead?
Here, I'm kicking myself. Your bisect clearly pointed at the problem (the addition of a broken CMakefile) but I didn't see it because it looked like python, not CMake. So I ignored it, went on a wild-goose chase. So I'm angry at myself for having missed the important clue. I'm trying not to be angry at the person who created the broken CMakefile. I'm more than a little irritated that the cmake infrastructure cannot automate this sort of stuff. There's all this mumbo-jumbo philosophy about file-globbing in cmake, but this is a case where that philosophy clearly failed. So I'm left with this mix: a missed clue, an incorrect cmakefile, and cmake as a tool that allows such mistakes to happen. And so the adventure ends...
After this commit, atomspace build throws a big number of errors, and the same is for the last commit.
I tried removing the double colon "::" in the first error
friend class ::ClassServerUTest
like in the fix for #50 and it doesn't throw that one, but still goes on to throw all the rest of the errors so there must be something I'm missing.