Problem with configure

[W. Tasin]

Michael Mueller wrote:
> 
> 
> In fact, the define comes from an environment variable which has to be set at compile
> time and is used to construct pathnames for directories (executables, temporary files and
> configuration files). So actually, the option would have to be
> -DSOMEPATH="${PATHVARIABLE}", but I first tried the simpler version without the
> environment variable and came to that problem. The environment variable is set
> differently for different products and for debug and release versions. A similar
> construct is used to bring a version string into the compiled software.
> Maybe I should note that we are currently investigating whether to use KDevelop for
> porting a large package of legacy software to Linux. I never had to deal with configure
> before using KDevelop, so I don't know much about it. May be it doesn't make sense for us
> to use configure, since it makes no sense to distribute our software because it can only
> be used together with very expensive hardware which only we build and sell. But KDevelop
> by default uses configure and so I first tried to do it this way. May be we will use
> KDevelop with only ordinary makefiles.
> 

Using only Makefile you will have the same problem, because the problem
you
described isn´t a problem of KDevelop but a problem of the shell
substitution.

And if you want to substitute environment variables you will have to
quote them inside double quotes (or outside any quotes) ... single
quotes won´t substitute env. variables, so this is an important
information ;-).

Using configure is only a way to simplify it and making it more
comfortable (if you know how to use it).

========
an example:
inserting in acconfig.h:
---
/* shows my path */ 
#undef SOMEPATH
---

inserting in configure.in (after AC_CHECK_COMPILERS):
---
if test -z "$MYENVPATH"; then
   MYENVPATH="/foo/default/value"
fi
AC_DEFINE_UNQUOTED(SOMEPATH, "${MYENVPATH}")
---
now you have only to invoke "make -f Makefile.dist" to update
config.h.in and configure.

then start 
./configure
(this uses the actual env setting and creates the Makefiles with this
setting)
or 
MYENVPATH="/foo/bla" configure
(this overrides the actual env setting temporarily)
---
if you change the environment variable MYENVPATH you have to rerun
configure
and remake the project.

with this solution:
changing the KDevelop options wouldn´t affect the result... 
it uses always the setting once defined with the configure call.
=======

another example with the -D switch:
inserting in configure.in (after AC_CHECK_COMPILERS):
---
if test -z "$MYENVPATH"; then
   MYENVPATH="/foo/default/value"
fi
CPPFLAGS="-DSOMEPATH='\""${MYENVPATH}"\"' $CPPFLAGS"
---
now you have only to invoke "make -f Makefile.dist" to update the
configure script.

then start 
./configure
(this uses the actual env setting and creates the Makefiles with this
setting)
or 
MYENVPATH="/foo/bla" configure
(this overrides the actual env setting temporarily and creates the
Makefile with /foo/bla)
or 
CPPFLAGS="-DSOMEPATH='\"/usr/test\"'" configure
or
make clean; make CPPFLAGS="-DSOMEPATH='\"/usr/test\"'"
(this overrides the actual setting of CPPFLAGS in the Makefiles)
========

Using configure, writing macro calls and scripts for configure.in can be
used to create configure switches like "configure --enable-xxx
--with-product-dir=/foo/bla" etc. etc.
to show another advantage of it.


> Regards,
> 
> Michael
Ciao

Walter
-- 
The KDevelop project: tasin at kdevelop.de [www.kdevelop.org]
--
oohhh sveglia.... il mondo e' ammalato, ma x colpa di chi.........
(Zucchero)
:-------W. Tasin, FB
04,FHM-------------------PGP-KeyID:0x7961A645----------:
<Key-Fingerprint: 1610 835F 0080 32F4 6140  6CF7 A7D0 44CD 7961A645>