Resistance was futile... :)
Without the excellent tip to keep a log of debug activities, that I picked up from the Udacity debugging course, I probably would have given up or would still be mud wresting this thing. (I will blog about this course next!)
The man who teaches this most excellent course is totally correct: the moment I started keeping notes instead of jamming my short term memory full of Vogon poetry, my brain was freed up to do some thinking, and I was able to take a break to snatch a few moments of real life without losing my spot.
It's amazing how much work a few lines of trivial looking code can make, and mind you, whilst it 'works' currently I had to cheat a little :)
Here is my (partial, since I forgot to keep it up at some points) log, in all it's gory:
AM_M macros do not work in autconf, try autoconf --force and that will
reset (something) and make it work once, but no more. Removed.
configure: WARNING: unrecognized options: --enable-maintainer-mode, --enable-gtest
1 Identify how many spurious warnings are generated
2 Examine Makefile for gbg_autoconf spoor
*make optional note in configure output to inform user this error
message is spurious* it is generated in generator/gen-py and almost
looks like code rot, is there a bug catergory for this, should this
be queued?
Note: build-outputs.mk still have references to gtest_LDFLAGS etc
gtest/gtest-1.la: $(gtest_DEPS)
cd gtest && $(LINK_CXX)) $(gtest_LDFLAGS) -o gtest-1.la $(LT_NO_UNDEFINED)
$(gtest_OBJECTS) $(LIBS)
WHY
Considering target file `all'.
File `all' does not exist.
Finished prerequisites of target file `all'.
Must remake target `all'.
g++ -Igtest_hack/include -Igtest_hack -c gtest_hack/src/gtest-all.cc
Putting child 0x090799a0 (all) PID 24007 on the chain.
Live child 0x090799a0 (all) PID 24007
Reaping winning child 0x090799a0 PID 24007
ar -rv libgtest.a gtest-all.o
Currently, the build system is "improving" our link command in two
ways:
1. it is stepping into gtest (not necessarily horrible)
2. it is adding all the objects fromthe compilation to the command line
FIX: Remove the extra compilation targets?
DONE: Change to build.conf
idea: make gtest a "exe"
Result: no change
Removed the headers from private-includes in build.conf
gtest/include/gtest/internal/*.h
gtest/include/gtest/*.h
This does not affect build behaviour. Also, it can't stay there
because gtest is optional and the script crashes when it cannot find
required headers.
Did this instead in Makefile.in: GTEST_INCLUDES = -Igtest -Igtest/include
Also added a lot of stuff into Makefile.in here is the current selection:
COMPILE_GTEST_CXX = $(COMPILE_CXX) $(GTEST_INCLUDES) -o $@ -c
LT_COMPILE = $(LIBTOOL) $(LTFLAGS) --mode=compile $(COMPILE) $(LT_CFLAGS)
LT_COMPILE_CXX = $(LIBTOOL) $(LTCXXFLAGS) --mode=compile $(COMPILE_CXX) $(LT_CFLAGS)
## I don't understand why, but I need to provide "-o ... -c" in order to get the
object file in the correct directory
LT_COMPILE_GTEST_CXX = $(LIBTOOL) $(LTCXXFLAGS)
--mode=compile $(COMPILE_CXX) $(LT_FLAGS) $(GTEST_INCLUDES) -o lib$@ -c
and also
LINK_GTEST_CXX = $(LIBTOOL) $(LTCXXFLAGS) --mode=link $(CXX) $(LT_LDFLAGS)
$(CXXFLAGS) $(LDFLAGS) -rpath $(libdir)
(forgot to document and prompty got lost and forgot what I did...)
idea: following the thread of the remake stack trace
------ completed all in apr-util
##>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
g++ -std=c++98 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -Wall -Wpointer-arith
-Wwrite-strings -Wshadow -Wunused -Wunreachable-code -Wno-system-headers \
-g3 -fno-omit-frame-pointer -fno-inline -DSVN_DEBUG -DAP_DEBUG -I./subversion/include
-I./subversion -I/home/g/trunk/apr/include -I/home/g/trunk/apr-util/incl\
ude -I/home/g/trunk/sqlite-amalgamation -Igtest -Igtest/include
-o gtest/src/gtest-all.lo -c gtest/src/gtest-all.cc
##<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
##>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
cd gtest && /bin/bash /home/g/trunk/libtool --tag=CXX --silent --mode=link g++
-g3 -fno-omit-frame-pointer -fno-inline -DSVN_DEBUG -DAP_DEBUG -rpath /tmp/foo/\
lib -o gtest-1.la src/gtest-all.lo
##<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
libtool: link: `src/gtest-all.lo' is not a valid libtool object
build-outputs.mk:479: *** [gtest/gtest-1.la] Error 1
#0 gtest/gtest-1.la at /home/g/trunk/build-outputs.mk:479
#1 gtest at /home/g/trunk/build-outputs.mk:1472
#2 local-all at /home/g/trunk/Makefile:390
#3 all at /home/g/trunk/Makefile:382
Command-line invocation:
Problem:
by including "-o $@", the output is named ".lo" instead of ".o". The reason
we added -o ... is to get the object file in the correct directory
TODO
should be building in the gtest directory
Ruby error : already at newest ruby, spurious warning?
get-deps.sh is giving an error message. Need to svn up at some point
Libtool won't link to a library not called libtool
Do we need to use libtool?
No, not necessarily, BUT the rest of SVN does and we would like to follow
their style
Ideas:
1. Avoid libtool
Pluses: might work
minus: might be harder than libtool
2. Hack gen-make.py
Pluses: ...
Minuses: serpents will issue forth from the CPU
3. Rename tree to libgtest
Pluses: Will work
Minuses: Kitten with ball of angora wool
4. libtool is actually a svn shell script. Is the restriction on
name inside the shell system? Why was it put in the first place?
Hack it if it exists?
Pluses: it might just work
Minuses: it might not
5. Get libtool compile command to add lib-prefix
Plus: right thing to do
test:
Yes it could work, although it puts the lib in trunk
TODO: Work out why/ask why it drops it in trunk
This involves changing the name of the targets all the way through the make
file
Plan
6: Rename target to libgtest
1. update configure.ac, build.conf
removed getst from aclocl.m4 in orig trunk as a test...
test if svn still compiles w/o gtest.m4 .. yes it does, removed.
PLAN: patch & ship
patched copy, didn't work, failed with:
/bin/bash /home/g/projects/svn/trunk/libtool --tag=CXX --silent --mode=compile g++ -
std=c++98 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -g -O2 -I./subve\
rsion/include -I./subversion -I/home/g/projects/svn/trunk/apr/include
-I/home/g/projects/svn/trunk/apr-util/include
-I/home/g/projects/svn/trunk/sqlite-amalgamat\
ion -Igtest -Igtest/include -o libgtest/src/gtest-all.lo -c gtest/src/gtest-all.cc
cd gtest && /bin/bash /home/g/projects/svn/trunk/libtool --tag=CXX --silent
--mode=link g++ -g -O2 -rpath /dev/null/lib -o libgtest-1.la src/gtest-all.lo
libtool: link: `src/gtest-all.lo' is not a valid libtool object
make: *** [gtest/libgtest-1.la] Error 1
g@musashi:~/projects/svn/trunk$ cd -
patch copy of faulty compile is the same as output of working one.
changed get_dep.sh to move unzipped gtest into libgtest instead
Added in dep-get.sh: warnings about the spurious warning about the
headers in autogen.sh and the repeated spurous warnings in ./configure
--enable-gtest,
*IT COMPILES* :)
cd libgtest && /bin/bash /home/g/projects/svn/trunk/libtool
--tag=CXX --silent --mode=link g++ -g -O2
-rpath /dev/null/lib -o libgtest-1.la
compile svn with gtest present but without flags test:
make clean
./configure --enable-maintaner-mode --prefix=/dev/null
make
PASS
compile svn without gtest present and without flags test:
make clean
./configure --enable-maintaner-mode --prefix=/dev/null
make
PASS
compile svn without gtest present and with flag test:
make clean
./configure --enable-maintaner-mode --prefix=/dev/null
make
PASS
roll patch, log & ship it.
