Re: AC_INIT receiving PACKAGE_VERSION from outside

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>>> "Sam" == Sam Steingold <sds@xxxxxxx> writes:

 Sam> what if my version is more complex?
 Sam> e.g.
 Sam> --------------------------------------------------------------
 Sam> # Version number and release date.
 Sam> VERSION_NUMBER=2.33.83
 Sam> RELEASE_DATE=2005-03-14      # in "date +%Y-%m-%d" format
 Sam> --------------------------------------------------------------
 Sam> do I need something like this:

 Sam> syscmd([. version.sh; echo "${VERSION_NUMBER} ${RELEASE_DATE}">version])
 Sam> AC_INIT([foobar], m4_normalize(m4_include([version])))
 Sam> syscmd([rm -f version])

Four comments:

1) Using syscmd or esyscmd is as dangerous as shell sourcing.
   Shell sourcing adds hidden dependencies to config.status;
   syscmd and esyscmd add hidden dependencies to configure.
   syscmd and esyscmd actually more evil because they allow
   side effects during autoconf runs.

2) The above scenario does not make sense to me.  Either your
   version number is `2.33.83', in which case that is what
   AC_INIT should get, or your version is `2.33.83 2005-03-14',
   in which case that is how VERSION_NUMBER should be defined.

   The second argument of AC_INIT is not a random string, it is
   also used to name the tarball.  If you want to display some
   additional information in addition to the version in your
   code, it's easy to use a dedicated variable for this purpose.

3) As I've suggested in my previous post, you can actually
   write `version' in a way that, like in your shell fragment
   above, it will define $VERSION_NUMBER and $RELEASE_DATE
   when sourced, and so that
     m4_normalize(m4_include([version]))
   will evaluate to `2.33.83 2005-03-14'.  Just give it a try.
   (Hint: dnl is your friend.)

4) Instead of constructing a version number before it is defined, 
   you can also break it apart after it has been defined.
-- 
Alexandre Duret-Lutz



_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
http://lists.gnu.org/mailman/listinfo/autoconf

[Index of Archives]     [GCC Help]     [Kernel Discussion]     [RPM Discussion]     [Red Hat Development]     [Yosemite News]     [Linux USB]     [Samba]

  Powered by Linux