[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kdevelop
Subject:    Re: Problem with configure
From:       "W. Tasin" <tasin () e-technik ! fh-muenchen ! de>
Date:       2000-04-28 23:12:01
[Download RAW message or body]

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@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>

[prev in list] [next in list] [prev in thread] [next in thread]