ardb rev. 158 fails to build on gentoo linux

[GoogleCodeExporter]

What steps will reproduce the problem?
1. sh make_linux.sh

First of all, i spotted a duplicate line in configure.in and a typo mistake
in src/Makefile.am, diff file is attached.

But i am still unable to compile the source, i attached the build log as well. 

First i thought build fails because of the version of gcc, then i tried to
compile with gcc-4.1.2 and then gcc-3.3.6 (i am using gcc-4.3.3 by
default). They all had given the same error and failed.

I am using libxml2-2.7.3
           libxslt-1.1.24
           wxGTK-2.8.9.1
           sqlite-2.8.16

Thinking that sqlite could be the reason, i downloaded source from cvs and
compiled by myself, in either case configure script couldn't determine the
PATH, so i edited Makefile and corrected it. After that build completed
successfully, and i ran the executable.

Please not that this same source is built successfully without any
modifications with same hardware on Mac OS 10.5.6 Leopard. But Mac OS is 64
bit and Linux is 32 bit.

Original issue reported on code.google.com by gokturk....@gmail.com on 18 Apr 2009 at 7:45

Attachments:

• ardb_revision_158_fix.diff
• ardb_revision_158_build.log
• gcc_info
• uname

[GoogleCodeExporter]

I also commented line 1012 of deckmodel.cpp out to get it compiled.

Original comment by gokturk....@gmail.com on 18 Apr 2009 at 7:50

[GoogleCodeExporter]

There is a problem with the configure script.  I modified it to work on MAC OS 
X and 
MINSYS on Windows.  It seems that this modification has broken the Linux build. 
 I 
need to look into how automake and autoconfig work so I can get this to work on 
all 
platforms.

I will look into line 1012.  Not sure what is happening here as this is code 
that has 
been there for a long time and has not changed recently.

Original comment by graham.r...@gmail.com on 18 Apr 2009 at 11:59

[GoogleCodeExporter]

Actually 1012 is new code.  I will check what the problem is.

Original comment by graham.r...@gmail.com on 18 Apr 2009 at 12:01

[GoogleCodeExporter]

To make configure work you need to pass the path to sqlite the configure script 
with 
the option --with-sqlite-prefix=

This is required because configure does not work on mingw and MAC OS X when 
using PKG_CHECK_MODULES(SQLITE, sqlite).  Sorry about this.  If anyone knows 
how to solve 
this please send me the fix.

Original comment by graham.r...@gmail.com on 19 Apr 2009 at 7:37

[GoogleCodeExporter]

I have checked in a new version of deckmodel.cpp.  Could you rebuild and see if 
it 
now compiles?

Original comment by graham.r...@gmail.com on 19 Apr 2009 at 2:29

• Changed state: Started
• Added labels: Type-Defect

[GoogleCodeExporter]

Positive, i just compiled a few minutes ago with my patch applied to the 
makefile, i didn't test it with the original 
makefile.
I have been studying GNU Build tools for last couple days, i am trying to come 
up with more stable configure.in 
and Makefile.am files. Now i am compiling it for Mac OS 10.5.6 Leopard with no 
modifications to the code on svn 
using make_macOSX script, Compilation just finished successfully.
BTW i didn't understand the purpose of acinclude.m4 under wxARDB/ , does this 
code have any hacks for kde or 
gnome? i removed it in linux and still it all worked fine.

Original comment by gokturk....@gmail.com on 19 Apr 2009 at 7:37

[GoogleCodeExporter]

I have no idea what the acinclude.m4 file is for.  As far as I can see there 
are no 
kde or gnome hacks. Good job on the Configure.in Makefile.am files.  Could you 
attached a copy so I can try them on mingw?

Original comment by graham.r...@gmail.com on 20 Apr 2009 at 8:15

[GoogleCodeExporter]

If you send me your email address I will give you write access to SVN.

Original comment by graham.r...@gmail.com on 20 Apr 2009 at 8:17

[GoogleCodeExporter]

I haven't written scripts yet but i'm working on it.
My idea on those scripts is that there shouldn't be any make_*.sh files under 
the
source tree hence configure script should be able to handle different OSes.
Right now, as far as i can see, the current problem is that configure cannot
determine sqlite. Why don't we first check for pkg-config, and then, 
conditionally,
use it to determine sqlite if it is installed on the system.
My email address is gokturk.yuksek __at__ gmail.com but i don't need a write
permission right now.

Original comment by gokturk....@gmail.com on 20 Apr 2009 at 9:03

[GoogleCodeExporter]

Checking for pkg-config sounds like a good solution.  How do we do this though?

Original comment by graham.r...@gmail.com on 20 Apr 2009 at 9:08

[GoogleCodeExporter]

This should do the trick, i was able to compile it with this patch, can you try 
it?

Original comment by gokturk....@gmail.com on 21 Apr 2009 at 3:46

Attachments:

• makefile_rev161.diff

[GoogleCodeExporter]

for some reason that i haven't found out yet, this patch breaks ".configure" 
for Mac OS, 

Original comment by gokturk....@gmail.com on 21 Apr 2009 at 5:06

[GoogleCodeExporter]

i found a web page[1] refers to the compilation issue in mac OS, the problem is 
PKG_CHECK_MODULES cannot be 
expanded because it is undefined in the system.

[1]: http://wiki.apache.org/thrift/FAQ

Original comment by gokturk....@gmail.com on 21 Apr 2009 at 5:41

[GoogleCodeExporter]

After spending few hours, i compiled the source under Mac OS too, but it 
shouldn't be a solution and never merged with the source tree. Here is how i 
did:

--- ardb.orig/wxARDB/configure.in   2009-04-17 04:10:31.000000000 -0400
+++ ardb/wxARDB/configure.in    2009-04-21 01:59:02.000000000 -0400
@@ -1,4 +1,4 @@
-@dnl Process this file with autoconf to produce a configure script.
+dnl Process this file with autoconf to produce a configure script.
 AC_INIT(aclocal.m4)

 AC_CANONICAL_SYSTEM
@@ -23,8 +23,6 @@

 AC_ARG_ENABLE(debug, [  --enable-debug          Enable debugging information],
               USE_DEBUG="$enableval", USE_DEBUG="no")
-AC_ARG_ENABLE(debug, [  --enable-debug          Enable debugging information],
-              USE_DEBUG="$enableval", USE_DEBUG="no")

 AC_MSG_CHECKING(for install location)
 case "$prefix" in
@@ -157,18 +155,25 @@
    use_mac=no
 fi

-dnl find sqlite
-AC_ARG_WITH(sqlite-prefix,
-[  --with-sqlite-prefix=PATH   location of libsqlite, eg. /usr/local],
-[
+dnl Find pkg-config.
+AC_CHECK_TOOL(PKGCONFIG_PATH, pkg-config, MISSING)
+
+dnl Find sqlite, use pkg-config to find it if possible.
+if test $PKGCONFIG_PATH = MISSING; then
+   AC_ARG_WITH(sqlite-prefix,
+   [  --with-sqlite-prefix=PATH   location of libsqlite, eg. /usr/local],
+   [
    case "$withval" in
-       n|no|y|ye|yes) ;; dnl Do nothing, we need it.
+        n|no|y|ye|yes) ;; dnl Do nothing, we need it.

-       *) sqlite_path=$withval ;;
-   esac
-])
+        *) sqlite_path=$withval ;;
+        esac
+        ])
    SQLITE_CFLAGS="-I $sqlite_path/include"
    SQLITE_LIBS="$sqlite_path/lib/libsqlite.a"
+else
+   PKG_CHECK_MODULES([SQLITE],[sqlite])
+fi

 AM_CONDITIONAL(USE_WINDOWS, test $use_windows = yes)
 AM_CONDITIONAL(USE_MACOS,   test $use_mac     = yes)
--- ardb.orig/wxARDB/make_macOSX.sh 2009-04-17 04:10:31.000000000 -0400
+++ ardb/wxARDB/make_macOSX.sh  2009-04-21 02:45:53.000000000 -0400
@@ -4,8 +4,9 @@
 # This script will help you build ARDB
 # 

-WX_CONFIG="/usr/local/bin/wx-config"
-#WX_CONFIG=`which wx-config`
+#WX_CONFIG="/usr/local/bin/wx-config"
+WX_CONFIG=`which wx-config`
+
 export PKG_CONFIG_PATH=/opt/local/lib/pkgconfig:/usr/local/lib/pkgconfig/

 if test "x$WX_CONFIG" = "x"
@@ -47,6 +48,21 @@
     echo "Failed"
     exit 1
 fi
+
+# Adding macros like PKG_CHECK_MODULES from pkg.m4 to aclocal.m4
+echo "Adding necessary macros to aclocal.m4 ..."
+if test -e aclocal.m4; then
+    if test -e pkg.m4; then
+   echo "\n" >> aclocal.m4
+   cat pkg.m4 >> aclocal.m4
+   echo "OK"
+    else
+   echo "Cannot find pkg.m4."
+    fi
+else
+    echo "Cannot find aclocal.m4, make sure that you run \"aclocal\"."
+fi
+
 #else 
 #    echo "Skipping aclocal"
 #fi

I added a macro that does look for pkg-config and then uses it to find sqlite, 
it works fine in Linux. However in mac os, PKG_CHECK_MODULES macro is 
undefined, i 
used a file called "pkg.m4" which originally resides under wxWidgets tree that 
has the definition for PKG_CHECK_MODULES to patch aclocal.m4 which is generated 
by 
"aclocal". 
Up to this point everything worked fine except one thing, because i compiled 
sqlite from the source without defining a prefix, it is located under 
/usr/local and who 
knows why pkg-config does not look that directory, your make_macOS.sh script 
solves this problem by exporting PKG_CONFIG_PATH.
We can use this method on our systems to generate binary files but adding these 
codes to the source tree makes it "our machine dependent" rather than 
"operating 
system independent".

Original comment by gokturk....@gmail.com on 21 Apr 2009 at 7:08

Attachments:

• ardb_rev161.diff
• pkg.m4

[GoogleCodeExporter]

I have another solution.
I add the sqlite 2 source tree to the SVN repository. (It is a pain getting the 
correct sqlite version from cvs).
We could change the build to use our local sqlite sources and library.  This 
will fix 
the package problems across the different platforms.

Original comment by graham.r...@gmail.com on 21 Apr 2009 at 7:43

[GoogleCodeExporter]

Or we rewrite the configure script.  But this seems a LOT of work for little 
gain.

Original comment by graham.r...@gmail.com on 21 Apr 2009 at 7:44

[GoogleCodeExporter]

Well adding whole sqlite ver_2 tree to our source tree does not really make any 
sense:
1) We need to keep a binary lib of sqlite, this makes whole code OS dependent. 
Because on which system we 
will compile sqlite? Even behaviour of stdlib differs  from one system to 
another. They handle dynamic linked 
libraries differently.
If we are just gonna keep the source of sqlite, why don't we just ask user to 
install beforehand?
2) Adding sqlite sources will make our sources grow.
3) Most of the GNU/Linux distros have their own package manager, using our own 
sqlite build may lead inconsistencies in future. Worse than that, i bet package 
maintainers will just refuse to keep such a source 
tree in their package repository.
4) By having scripts like make_*.sh in our source tree, we actually kill the 
whole idea of autoconf and 
automake. They are there to generate shell scripts for multiple platforms and 
handle lib dependencies.
5) Having sqlite binary in tree is also an ethical issue if you ask me, how 
would users be sure that this 
executable has no malicious codes in it.

Have you ever tried to type 'make distcheck', and then compile that tar.gz 
file. It fails so bad.

I have no single idea about developing environment in windows, i wrote codes in 
C# using .net with emacs 
under linux for an entire semester, but i think none of the windows folks wanna 
compile it from sources as 
long as they can 'double click' it.

As a consequence, for many reasons we should have a modular tree and be able to 
compile it in 6 steps:
% aclocal
% autoconf
% automake --add-missing
% ./configure
% make
% make install

My suggestion is that while current developers are contributing the code and 
enhancing the UI, we can have 
another folder in svn, for example ardb2, which aims to have a well designed 
source tree. And hopefully get 
the work done before 2.0 release.

Original comment by gokturk....@gmail.com on 21 Apr 2009 at 8:27

[GoogleCodeExporter]

I agree with your points above if we where only targeting Linux.  But we are 
not.  We  
have 3 different OSes we need to build on easily.  The sqlite v2 source code is 
a 
pain to checkout and has lead to difficulties on all OSes.  I have fixed the 
sqlite 
source in SVN so it builds on Linux, Mac OS X and mingw.  All you have to do is 
build 
this version and then link to the libs it produces.  There are no binary libs 
for 
sqlite checked in to SVN.

Original comment by graham.r...@gmail.com on 21 Apr 2009 at 8:49

[GoogleCodeExporter]

If you want to try and fix the autoconf I will give you write access so you can 
branch the trunk.  This is better then adding a new version to svn.

Original comment by graham.r...@gmail.com on 21 Apr 2009 at 8:54

[GoogleCodeExporter]

To be honest with you, i would try to fix it locally on my laptop rather than 
messing up with the sources already 
in svn :)
I think i will try to write the whole script from scratch and try to see what i 
can do.

Original comment by gokturk....@gmail.com on 21 Apr 2009 at 9:04

[GoogleCodeExporter]

OK.  If you can that would be great.  It would be good if it could operate 
without 
using PKG_CHECK_MODULES.

Original comment by graham.r...@gmail.com on 21 Apr 2009 at 9:07

[GoogleCodeExporter]

why don't you want to use PKG_CHECK_MODULES?

Original comment by gokturk....@gmail.com on 21 Apr 2009 at 9:14

[GoogleCodeExporter]

I thought it was not available on MAC OS X or mingw. Or is the problem that it 
is not 
in our aclocal.m4 file?

If you can get it to build on MAC OS X using PKG_CHECK_MODULES use it.

Original comment by graham.r...@gmail.com on 21 Apr 2009 at 9:20

[GoogleCodeExporter]

I have already sent the patch that makes use of pkg-config available on mac os, 
 btw can you grant me access to 
wiki, i may write a wiki about how to build it on gentoo, 

Original comment by gokturk....@gmail.com on 21 Apr 2009 at 9:25

[GoogleCodeExporter]

Sorry.  I just noticed.  You've been added.

Original comment by graham.r...@gmail.com on 21 Apr 2009 at 9:35

[GoogleCodeExporter]

Thanks

Original comment by gokturk....@gmail.com on 21 Apr 2009 at 9:36

[GoogleCodeExporter]

May i ask you why DeckUpload 's naming convention is different than other 
sources?

Original comment by gokturk....@gmail.com on 21 Apr 2009 at 9:59

[GoogleCodeExporter]

I created it on windows which does not care about caps.  I forgot to change it 
to 
lower case when I checked it in.

Original comment by graham.r...@gmail.com on 21 Apr 2009 at 10:13

[GoogleCodeExporter]

ardb.rc:
--------------------
icon ICON icon.ico

#include "wx/msw/wx.rc"
--------------------

There is no icon.ico under source tree but icon.xpm instead. Do you think this 
should be fixed?

And also can you change DeckUpload to all-lowercase, so that people don't get 
confused about that later.

Original comment by gokturk....@gmail.com on 22 Apr 2009 at 1:57

[GoogleCodeExporter]

Changing the file case is really hard on Windows.  This will need to be done 
from 
linux of mac os x.

The icon is the the resources directory udex wxArdb

Original comment by graham.r...@gmail.com on 22 Apr 2009 at 6:09

[GoogleCodeExporter]

I think I can close this now.  Noone has reported that the last version cannot 
be 
built.

Original comment by graham.r...@gmail.com on 20 Feb 2010 at 3:59

• Changed state: Fixed