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
