On 23 Sep, 03:15, "yoursurrogate...@gmail.com"
wrote:
> Ok, at my company we are using autotools in order to make our
> makefiles and compile our code. Here is the issue. We have a project
> that goes across 3 different source trees (long story). Each has its
> own configure.ac file. We can include a Common.ac file in each of the
> files in order to create a single area where a bunch of variables can
> be changed (thereby not needing to make the same changes in each of
> the 3 configure.ac files in different source trees). This works fine
> for some things. However. Lets look at the below example for an
> illustration:
>
> AC_PREREQ(2.52)



Seriously consider upgrading.



> AC_INIT([Project1], [Version1], [f...@bar.org])
> AC_CONFIG_HEADER(config.h)
>
> # Checks for programs.
> AC_PROG_CXX([g++32])
> AC_PROG_CPP([g++32])
> AC_PROG_CC([g++32])
> AC_PROG_INSTALL
> AC_PROG_LN_S
> AC_PROG_RANLIB
> AC_PROG_AWK
>
> I would like to set the values of g++32 for AC_PROG_CXX, AC_PROG_CPP
> and AC_PROG_CC, as well as the version and e-mail in AC_INIT from a
> single source. I tried to include a file for both. But that didn't
> work when I ran autoreconf and it went through it without noticing (or
> so it seemed). I would also like to stay within the bounds of the
> autotools and not have to resort to kludgy implementations.


Why not rename "Common.ac" "configure.ac" and make it the same
for all three trees? But the better solution is probably to merge the
projects.

If for some reason you can't combine the trees into
one, maybe you should consider AC_CONFIG_SUBDIRS.
It won't address the problems you mention, but it is
probably worth considering.


Why do you want to prefer g++32
as your C compiler? C++ is not C, and C++ compilers
are not C compilers.

On Sep 22, 10:43*pm, William Pursell wrote:
> On 23 Sep, 03:15, "yoursurrogate...@gmail.com"
>
> wrote:
> > Ok, at my company we are using autotools in order to make our
> > makefiles and compile our code. Here is the issue. We have a project
> > that goes across 3 different source trees (long story). Each has its
> > own configure.ac file. We can include a Common.ac file in each of the
> > files in order to create a single area where a bunch of variables can
> > be changed (thereby not needing to make the same changes in each of
> > the 3 configure.ac files in different source trees). This works fine
> > for some things. However. Lets look at the below example for an
> > illustration:
>
> > AC_PREREQ(2.52)
>
> Seriously consider upgrading.
>
I think our latest version is 2.69ish... don't remember. I just had to
snag that from some example online since I can't take code from work
and post it here. Proprietary rules and regulations...
>
>
> > AC_INIT([Project1], [Version1], [f...@bar.org])
> > AC_CONFIG_HEADER(config.h)
>
> > # Checks for programs.
> > AC_PROG_CXX([g++32])
> > AC_PROG_CPP([g++32])
> > AC_PROG_CC([g++32])
> > AC_PROG_INSTALL
> > AC_PROG_LN_S
> > AC_PROG_RANLIB
> > AC_PROG_AWK
>
> > I would like to set the values of g++32 for AC_PROG_CXX, AC_PROG_CPP
> > and AC_PROG_CC, as well as the version and e-mail in AC_INIT from a
> > single source. I tried to include a file for both. But that didn't
> > work when I ran autoreconf and it went through it without noticing (or
> > so it seemed). I would also like to stay within the bounds of the
> > autotools and not have to resort to kludgy implementations.
>
> Why not rename "Common.ac" "configure.ac" and make it the same
> for all three trees? *But the better solution is probably to merge the
> projects.
>
> If for some reason you can't combine the trees into
> one, maybe you should consider AC_CONFIG_SUBDIRS.
> It won't address the problems you mention, but it is
> probably worth considering.
>
What does it do? Is there *any* way to set the version and contact
information when autoreconf is run?
> Why do you want to prefer g++32
> as your C compiler? *C++ is not C, and C++ compilers
> are not C compilers.

Generally you should be able to compile C code with C++ compilers.
I've heard it being recomended since the C++ compiler does more
checking and produces safer code than the C compiler. Also, we have a
few C source files. If they're not compiled with the C++ compiler,
then when they are linked, you get very strange and obscure linker
errors.

And combining the 3 source trees into one, is kind of out of the
question at the moment .

> What does it do? Is there *any* way to set the version and contact
> information when autoreconf is run?
>> Why do you want to prefer g++32
>> as your C compiler? Â*C++ is not C, and C++ compilers
>> are not C compilers.
>
> Generally you should be able to compile C code with C++ compilers.

most C will work with C++ compilers - doesn't mean all C will.
if the C++ compiler complains it doesn't mean that there's mistakes in
the C

> I've heard it being recomended since the C++ compiler does more
> checking and produces safer code than the C compiler.

I can't see a C++ compiler doing a better job of compiling C than
a C compiler.

> Also, we have a
> few C source files. If they're not compiled with the C++ compiler,
> then when they are linked, you get very strange and obscure linker
> errors.

if the C files are correctly written, then there are errors in the C++
files, probably where the C function prototypes are invoked.

Bye.
Jasen