Peter Daniel Kirchner wrote: > > 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
I think a general --with-my-includes or --with-extra-includes will be great. -- [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
