Re: [Squid Web Proxy Wiki] Update of "Features/ConfigureInRefactoring" by FrancescoChemolli

On Tue, Nov 24, 2009 at 1:29 AM, Amos Jeffries <squid3_at_treenet.co.nz> wrote:
> On Mon, 23 Nov 2009 17:04:14 -0000, wiki_at_wiki.squid-cache.org wrote:
>> Dear Wiki user,
>>
>> You have subscribed to a wiki page or wiki category on "Squid Web Proxy
>> Wiki" for change notification.
>>
>> The "Features/ConfigureInRefactoring" page has been changed by
>> FrancescoChemolli:
>>
> http://wiki.squid-cache.org/Features/ConfigureInRefactoring?action=diff&rev1=2&rev2=3
>>
>> Comment:
>> added some case notes
>>
>>
>>   RobertCollins suggests to also include making use of
>>   [[https://edge.launchpad.net/pandora-build|Pandora Build]], a set of
>>   cross-project and cross-system configuration resources.
>>
>> +
>> + '''Case notes'''
>> +
>> + In order to further modularize configure.in it would be useful to
> split
>> some helper definition files out of configure.in itself, to an included
>> modular file. A name for such file is to be defined, at the moment it's
>> named {{{squidinclude.m4}}}, to be included from {{{configure.in}}} (and
>> not from {{{aclocal.m4}}}, because in this case
>> + the inclusion would happen too soon).
>> +
>> + As a first attempt I've successfully extracted the
>> AC_TEST_CHECKFORHUGEOBJECTS call, which is now much cleaner and well
>> layered. It includes compiler detection, caching and a generic
>> infrastructure for compiler arguments detection.
>
>
>  * local Squid-provided helper macros are currently defined in
> acinclude.m4

acinclude.m4 is include before AC_INIT. Thus some infrastructure is
not available there, and several macros cannot be used.

> The only improvement we could make to that design is to upgrade to the
> style of a folder full of macro files. One macro per file with author
> copyright etc attached.

Doable.

> Yes, some chunks of configure.in should be isolated and moved into bundled
> macros instead.
>
>  * HUGEOBJECTS was already one such macro. How are you changing things
> there?

HUGEOBJECTS re-implemented part of the macro compiler, I assume due to
the too-early inclusion.
Here's the version I came up with (BTW: it seems that with recent
gcc's it's actually deprecated...)

=== HUGEOBJECTS ORIGINAL ===
AC_DEFUN([AC_TEST_CHECKFORHUGEOBJECTS],[
 if test "$GCC" = "yes"; then
  AC_MSG_CHECKING([whether compiler accepts -fhuge-objects])
  AC_CACHE_VAL([ac_cv_test_checkforhugeobjects],[
    ac_cv_test_checkforhugeobjects=`echo "int main(int argc, char
**argv) { int foo; }" > conftest.cc
${CXX} -Werror -fhuge-objects -o conftest.bin conftest.cc 2>/dev/null
res=$?
rm -f conftest.*
echo yes
exit $res`
    if [[ $? -ne 0 ]]
    then ac_cv_test_checkforhugeobjects=no
    else if [[ -z "$ac_cv_test_checkforhugeobjects" ]]
         then ac_cv_test_checkforhugeobjects=yes
    fi ; fi
  ]) # end of CACHE_VAL
  AC_MSG_RESULT([${ac_cv_test_checkforhugeobjects}])

  if test "X${ac_cv_test_checkforhugeobjects}" != Xno
  then
    HUGE_OBJECT_FLAG="-fhuge-objects"
  else
    HUGE_OBJECT_FLAG=""
  fi
 fi
]) # end of AC_DEFUN of AC_TEST_CHECKFORHUGEOBJECTS

=== HUBEOBJECTS CANDIDATE ===
AC_DEFUN([AC_TEST_COMPILER_FLAG],[
  AC_CACHE_CHECK([whether compiler accepts $2],[$1],
  [{
    SAVED_FLAGS="$CFLAGS"
    SAVED_CXXFLAGS="$CXXFLAGS"
    CFLAGS="$CXXFLAGS $2"
    CXXFLAGS="$CXXFLAGS $2"
    AC_TRY_LINK([],[int foo; ],
      [$1=yes],[$1=no])
    CFLAGS="$SAVED_CFLAGS"
    CXXFLAGS="$SAVED_CXXFLAGS"
  }])
])

AC_DEFUN([AC_TEST_CHECKFORHUGEOBJECTS],[
  AC_LANG_PUSH([C++])
  if test "$GCC" = "yes"; then
    AC_TEST_COMPILER_FLAG([ac_cv_test_checkforhugeobjects],[-Werror
-fhuge-objects])
  else
    ac_cv_test_checkforhugeobjects=no
  fi
  AC_LANG_POP([C++])
])

=== END ===

The candidate is 7 lines shorter, much more portable and readable,
properly handles non-gcc cases, AND it offers one more high-level
function allowing to test any compiler flag with any compiler, with
proper result caching etc.

-- 
    /kinkie