Question about dead code in build-infra/common/autoconf/basics.m4

[David Holmes]

Hi Tim,

The order of inclusion and definition is different from the order of 
execution. configure.ac includes all the m4 files and so gets the 
various function definitions, then it executes the functions eg:

  # Basic initialization that must happen first of all
  BASIC_INIT
  BASIC_SETUP_PATHS
  BASIC_SETUP_LOGGING

  # Must be done before we can call HELP_MSG_MISSING_DEPENDENCY.
  HELP_SETUP_DEPENDENCY_HELP
...


That said PLATFORM_SETUP_OPENJDK_BUILD_OS_VERSION is called after the 
above, so it does appear that the order is wrong here. I can't see 
exactly where OPENJDK_BUILD_OS is getting set in the setup files, but 
looking at where it gets set in generated-configure.sh it certainly 
appears to be be getting set after it's use.

David
-----


On 17/09/2012 1:57 PM, Tim Bell wrote:
> Hello - this may be basic autoconf knowledge, but here goes:
>
> % cat -n build-infra/common/autoconf/basics.m4
> [... snip ...]
>> 162 AC_DEFUN_ONCE([BASIC_SETUP_PATHS],
>> 163 [
>> 164 # Where is the source? It is located two levels above the
>> configure script.
>> 165 CURDIR="$PWD"
>> 166 cd "$AUTOCONF_DIR/../.."
>> 167 SRC_ROOT="`pwd`"
>> 168 if test "x$OPENJDK_BUILD_OS" = "xwindows"; then
>> 169 SRC_ROOT_LENGTH=`pwd|wc -m`
>> 170 if test $SRC_ROOT_LENGTH -gt 100; then
>> 171 AC_MSG_ERROR([Your base path is too long. It is $SRC_ROOT_LENGTH
>> characters long, but only 100 is supported])
>> 172 fi
>> 173 fi
>> 174 AC_SUBST(SRC_ROOT)
>> 175 cd "$CURDIR"
>> 176
>> 177 SPACESAFE(SRC_ROOT,[the path to the source root])
>> 178 SPACESAFE(CURDIR,[the path to the current directory])
>> 179 ])
>
> Based on my experiments this evening, lines 169...172 will never be
> executed, because OPENJDK_BUILD_OS does not have a value at this point.
> The if test at line 168 evaluates to false, even on Windows build systems.
>
>
> OPENJDK_BUILD_OS is defined in platform.m4, lines 358 ... 371
>
>
>
> I see that all the .m4 files are rolled up in configure.ac, like this:
>
> % grep m4_include configure.ac
> m4_include([build-aux/pkg.m4])
> m4_include([basics.m4])
> m4_include([builddeps.m4])
> m4_include([boot-jdk.m4])
> m4_include([build-performance.m4])
> m4_include([help.m4])
> m4_include([jdk-options.m4])
> m4_include([libraries.m4])
> m4_include([platform.m4])
> m4_include([source-dirs.m4])
> m4_include([toolchain.m4])
>
>
> Is the include order significant? It appears to me that it is, and the
> 'earlier' .m4 files can not rely on anything done in the 'later' files.
>
> Am I missing something here?
>
> Thanks-
>
> Tim
>
>