Tuesday 5 February 2013

Build System Gtest addition, next attempt



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.