Thanks for the thoughtful arguments, which I find convincing. There is still nothing GL-specific. Can we generalize to e.g. --with-my-includes (or is there some open source convention)? Pete
Jose Gomes wrote: > Peter Daniel Kirchner wrote: > > > > Thanks for the submission. I like i & iii and can input the changes > > (unless there is another volunteer). I have some misgivings about ii > > --adding a gl-specific customization for libs > > and includes. Do you object to CFLAGS, CPPFLAGS and LDFLAGS for this > > purpose (and which also accommodate many other customizations)? > > Regards, > > Pete > > > > Jose Gomes wrote: > > > > > Hello, > > > > > > I have dx built, installed and running for linux and solaris > > > and would like to report 3 problems. The fixes can be found > > > in the file in attachment (which is the output of "cvs diff -C3"). > > > Please let me know if something is wrong with this. > > > I hope this will help. > > > > > > Best regards, > > > > > > Jose Gomes > > > > > > ----------------------------------------------------------------------- > > > Following are the three bugs description, labeled i), ii) and iii). > > > > > > i) > > > > > > The main problem is that the Makefile.am's are not written > > > to support both builddir==srcdir and builtdir!=srcdir > > > which was required for me since I wanted > > > to compile it for two architectures and which is (as far as I > > > know) the standard way to use the gnu tools. > > > So I had to change in almost every Makefile.am's > > > lines like: > > > INCLUDES = -I../../../include [EMAIL PROTECTED]@ > > > by lines like: > > > INCLUDES = -I$(srcdir)/../../../include [EMAIL PROTECTED]@ > > > Another modification is due to the fact that c++ sources are generated > > > automatically by a script called "class" which asssumed that > > > srcdir==builddir. > > > So this script is slightly modified so that it can > > > be passed the srcdir directory as argument. > > > See below for a list of the modified files. > > > > > > ii) > > > > > > My opengl headers and libraries are not is a standard place. > > > I added the options --with-gl-includes and --with-gl-libs > > > to the "configure" script so that these locations can be passed > > > to all Makefile.am through the variables GL_INCLUDES and GL_LIBS. > > > See bellow for a list of modified files. > > > > > > iii) > > > > > > I have flex installed for solaris and the scripts think that > > > linux implies flex and solaris implies lex. > > > The problem is that flex and lex are not compatible. > > > The file src/uipp/dxuilib/Network.C uses the "yylineno" > > > variable which does not exists in flex but does in lex. > > > This was taken into account in this C file by: > > > #if defined(linux) || defined(cygwin) || defined(freebsd) > > > int yylineno; > > > #else > > > extern int yylineno; /* lexer line number */ > > > #endif > > > I think it is not the correct test since the fact "yylineno" exists > > > is just a matter of "lex" or "flex". > > > So, instead of adding the test "|| defined(solaris)", I hadded the > > > autoconf variable "HAVE_YYLINENO" (initialized by "configure") > > > and replace the previous code by: > > > #ifndef HAVE_YYLINENO > > > int yylineno; > > > #else > > > extern int yylineno; /* lexer line number */ > > > #endif > > > See below for a list of modified files. > > > > > > Following are the list of modified files for fixing the 3 bugs. > > > > > > builddir==srcdir > > > --------------- > > > > > > M acconfig.h > > > M configure.in > > > M src/exec/dpexec/Makefile.am > > > M src/exec/dpexec/local.mk > > > M src/exec/dxexec/Makefile.am > > > M src/exec/dxmods/Makefile.am > > > M src/exec/hwrender/Makefile.am > > > M src/exec/hwrender/opengl/Makefile.am > > > M src/exec/libdx/Makefile.am > > > M src/exec/libdx/class > > > M src/exec/libdx/local.mk > > > M src/misc/Makefile.am > > > M src/uipp/base/Makefile.am > > > M src/uipp/dxl/Makefile.am > > > M src/uipp/dxui/Makefile.am > > > M src/uipp/dxuilib/Makefile.am > > > M src/uipp/dxuilib/Network.C > > > M src/uipp/java/Makefile.am > > > M src/uipp/mb/Makefile.am > > > > > > Non standard gl location. > > > ------------------------- > > > > > > M configure.in > > > M src/exec/dxexec/Makefile.am > > > M src/exec/hwrender/Makefile.am > > > M src/exec/hwrender/opengl/Makefile.am > > > > > > No yylineno in flex. > > > -------------------- > > > > > > M acconfig.h > > > M configure.in > > > M src/uipp/dxuilib/Network.C > > > > > > -- > > > [EMAIL PROTECTED] Tel. +33 4 92 38 76 48 > > > http://www.inria.fr/robotvis/personnel/jgomes > > > Projet RobotVis, INRIA, 2004, route des Lucioles - B.P. 93 > > > F-06902 Sophia Antipolis Cedex, FRANCE > > > > > Hello, thank your very much for your answer. > I think indeed i) and iii) are more important than ii) and one can > indeed > manage without it by setting correctly variables like CFLAGS. > Nevertheless, I can give some additional arguments (It is true that I > gave no convincing > arguments in my last mail) to adopt ii). > I am not telling it is the best to do but just discussing so that > you (and all of us) can decide what is the best to do. > I will not insist further after this mail since it is not very > important. > Thanks again and best regards, > > Jose. > > Folowing are two arguments for adopting ii) (see last mail) > > a) > The main argument fot ii) is that final users who want to install > dx should not have to edit install files like configure.in or > Makefile.am's. > I thing all of us agree this requirement but I can just give on reason: > if you are installing dx for multiple architecture you don't want > neither > to edit install files each time you compile nor to have multiple srcdir > because > it is not natural to have to touch the srdir to change from one > architecture to another. > If one have to do so, it means that the package is not portable. > Another reason why one should not edit customization in install files is > that > you and me certainly don't want to have different source files: the > final goal fo a well > done package is that the source files are the same for evrybody. > So according to this remarks, the only way to do some customization is > at > build time when calling configure like this: > setenv CFLAGS /net/home/robotvis/Mesa/include && setenv LDFLAGS > /net/home/robotvis/Mesa/lib && ../../configure ... > which works fine (and is your proposition). The b) part gives one reason > not to do so: > > b) > The advantage of using configure options is that these options are > cached in the file > config.status. Indeed, the first lines of this script are supposed to > store everything > about the way the build directory was built. If you pass to configure > informations through > envieronmment variables, these settings are lost for ever (unless you > make your own script > but it is not natural since gnu tools provide many script and one do not > want to add his > own ad-hoc, non standard scripts). > Using configure options makes the config.status first lines to include > thinks like: > ../../dx/configure --prefix=/tmp/dx > --with-gl-includes=/u/corse/2/robotvis/Mesa/include > --with-gl-libs=/u/corse/2/robotvis/Mesa/lib --without-javadx > which makes it easy to reproduce the same thing later. > Obviously, it is not possible to add too many configure options but I > thing > that OpenGl location tuning is important for a visualization package > like dx > and it can occur very often that OpenGl is not installed in a > predictable place > (because for example one uses Mesa and not native OpenGl librarie). > > -- > [EMAIL PROTECTED] Tel. +33 4 92 38 76 48 > http://www.inria.fr/robotvis/personnel/jgomes > Projet RobotVis, INRIA, 2004, route des Lucioles - B.P. 93 > F-06902 Sophia Antipolis Cedex, FRANCE
