Autotools: Reading in value for version and contact information forconfigure.ac - Linux

This is a discussion on Autotools: Reading in value for version and contact information forconfigure.ac - Linux ; 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 ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: Autotools: Reading in value for version and contact information forconfigure.ac

  1. Autotools: Reading in value for version and contact information forconfigure.ac

    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)
    AC_INIT([Project1], [Version1], [foo@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.

  2. Re: Autotools: Reading in value for version and contact informationfor configure.ac

    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.

  3. Re: Autotools: Reading in value for version and contact informationfor configure.ac

    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.

  4. Re: Autotools: Reading in value for version and contact informationfor configure.ac

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

  5. Re: Autotools: Reading in value for version and contact informationfor configure.ac

    > 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

+ Reply to Thread