jimzah/openafs
1
0
Fork 0
mirror of https://git.openafs.org/openafs.git synced 2025-01-18 06:50:12 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity
052f274c3c
openafs/configure.ac

199 lines
5.5 KiB
Plaintext
Raw Normal View History

Use autoconf-archive m4 from src/external Switch to using the m4 macros from autoconf-archive in our src/external mechanism, instead of manually-copied versions in src/cf. The src/external copy of ax_gcc_func_attribute.m4 is identical to the existing copy in src/cf, so that should incur no changes. There are also a few new macros pulled in, but they are currently unused. Increase our AC_PREREQ in configure.ac to 2.64, to match the AC_PREREQ in some of the new files. Change-Id: I8acfe4df7b9a22d9b9e69004c3438034a2dacadb Reviewed-on: https://gerrit.openafs.org/14135 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
2020-04-05 04:35:07 +01:00
AC_PREREQ([2.64])
autoconf: updates and cleanup Update autoconf macros to their modern equivalents, according to what the 'autoupdate' tool does. While we're here, remove automake references that aren't being used, and remove the obsolete AC_PROG_LIBTOOL in favor of AFS_LT_INIT. Change-Id: I71066d6d72f8b1d8663e26fec83ae23d7f73f059 Reviewed-on: https://gerrit.openafs.org/12199 Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: BuildBot <buildbot@rampaginggeek.com>
2016-02-29 18:19:01 +00:00
AC_INIT([OpenAFS],[m4_esyscmd(build-tools/git-version .)],[openafs-bugs@openafs.org],[],[http://www.openafs.org/])
Move build support files into build-tools Now that we have a build-tools directory, move the various support files used by Autoconf and Automake into it as well to reduce clutter at the top level. Change-Id: Ieae317524d5354e3a6168507c569378f7913b05f Reviewed-on: http://gerrit.openafs.org/2432 Tested-by: Russ Allbery <rra@stanford.edu> Reviewed-by: Derrick Brashear <shadow@dementia.org> Tested-by: Derrick Brashear <shadow@dementia.org>
2010-07-15 01:29:34 +01:00
AC_CONFIG_AUX_DIR([build-tools])
Add libtool support Add support for using libtool to the Unix build system to build both pthreaded and lwp libraries. For purely pthread libraries, this just provides convenience macros to invoke the standard GNU libtool from the OpenAFS build system. For libraries that have lwp variants, we provide an initial wrapper script - lwptool, which handles building a non-PIC LWP object before asking libtool to build the pthread variants. For a given source example.c, example.o is the non-PIC pthread object, .libs/example.o is the PIC pthread object, and .lwp/example.o is the LWP object. To use libtool for a particular library directory, add the line include @TOP_OBJDIR@/src/config/Makefile.libtool to the file's preamble. Makefile.pthread, or Makefile.lwp should be included as normal to indicate whether the libraries in this Makefile are pthread only, or should be built for both pthread and LWP objects. The variables LT_current, LT_revision and LT_age may be used to control the version of the shared objects produced. They have the same meaning as that documented in the Versioning section of the libtool manual. The LT_objs variable should be set to a space separated list of the .lo objects included in the library. Note that there should _never_ be a dependency on the .o form of these objects in the Makefile, as this breaks parallel builds. LT_deps is a list of the libtool dependencies of the library, and LT_libs is a list of the external (non-OpenAFS) library dependencies. A file called <libraryname>.sym should be created which contains a newline seperated list of all of the symbols exported from this library. LWP library names remain the same as always. To distinguish the pthreaded static and shared libraries these LWP libraries should be linked using libexample.a: $(LT_objs) $(LTLWP_LDLIB) $(LT_objs) Shared libraries should be linked using libexample.la: $(LT_objs) $(LT_deps) (note that the pattern rules in the included Makefile take care of the build rule here) If necessary, static convenience libraries can be produced using: libconvenience.a: $(LT_objs) $(LTLWP_LDLIB_static) $(LT_objs) PIC convenience libaries can be linked using: libconvenience_pic.a: $(LT_objs) $(LTLWP_LDLIB_pic) $(LT_objs) Libtool libraries should be installed using the $(LT_INSTALL_DATA) macro Binaries linking agains libtool libraries should be linked using the $(LT_LDRULE) or $(LT_LRDULE_static) options, with library paths in the built locations relative to the top of the tree. For example example_test: example_test.o $(top_builddir)/src/example/libexample.la $(LT_LDRULE) example_test.o \ $(top_builddir)/src/example/libexample.la Change-Id: I32b162e8443119e8115febc532c5b5a0ec8fed32 Reviewed-on: http://gerrit.openafs.org/8033 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Derrick Brashear <shadow@dementix.org>
2012-05-21 08:57:05 +01:00
AC_CONFIG_MACRO_DIR([src/cf])
Autoconf: Update AC_INIT macro use Update the way that we use the AC_INIT macro to match current autoconf conventions Change-Id: Ib1ce2acd879683ff8ff178cfbd9776277ba7460f Reviewed-on: http://gerrit.openafs.org/2265 Reviewed-by: Derrick Brashear <shadow@dementia.org> Tested-by: Derrick Brashear <shadow@dementia.org>
2010-06-26 17:39:20 +01:00
AC_CONFIG_SRCDIR([src/config/stds.h])
autoconf: Remove/update obsolete autoconf macros Autoconf 2.70 (released in 2020-12) produces warning messages about obsolete constructs by default. Running regen.sh with autoconf 2.70 installed produces the following warnings: .. configure.ac:7: warning: The macro `AC_CONFIG_HEADER' is obsolete. configure.ac:21: warning: AC_PROG_LEX without either yywrap or noyywrap is obsolete configure.ac:21: warning: The macro `AC_HEADER_STDC' is obsolete. configure.ac:21: warning: The macro `AC_HEADER_TIME' is obsolete. .. Replace AC_CONFIG_HEADER with AC_CONFIG_HEADERS Add the noyywrap parameter to AC_PROG_LEX. Use the noyywrap option since we already provide a yywrap function in the .l sources. Remove AC_HEADER_STDC. There are no references to the the autoconf variable set by this macro. This macro was marked as obsolete prior to autoconf 2.64 with the following note: "This macro is obsolescent, as current systems have conforming header files. New programs need not use this macro." AC_HEADER_TIME was marked as obsolete prior to autoconf 2.64 with the following note: "This macro is obsolescent, as current systems can include both files when they exist. New programs need not use this macro." The only reference that requires AC_HEADER_TIME is within the external roken code pulled from heimdal. Compiles that use the external upstream heimdal packages result in a build error if TIME_WITH_SYS_TIME is not defined: building src/crypto/hcrypto src/external/heimdal/hcrypto/camellia.c include/roken.h:803:58: error: ‘struct tm’ declared inside Update autoheader.m4 so a define for TIME_WITH_SYS_TIME is created. This avoids modifying the external heimdal/roken code. Change-Id: If4d6c0650aac617f535b35f81994b54a3b8ac021 Reviewed-on: https://gerrit.openafs.org/14838 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
2021-11-02 15:18:51 +00:00
AC_CONFIG_HEADERS([src/config/afsconfig.h])
Make OpenAFS 1.9.1 Update version strings for the second 1.9.x development release. Change-Id: I318ff00f02f618e0a25571a3c957ae6a6500e65c Reviewed-on: https://gerrit.openafs.org/14560 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
2021-03-19 01:50:35 +00:00
MACOS_VERSION=1.9.1
macos-version-generation-20071011 make release time simpler
2007-10-11 18:51:56 +01:00
build-sys: use m4 quoting consistantly Change-Id: Ie8c5e15fd9ddf521ac74b07ee0e1252b35e7a816 Reviewed-on: http://gerrit.openafs.org/10008 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
2013-06-22 17:28:01 +01:00
AC_SUBST([MACOS_VERSION])
introduce-autoconf-for-openafs-20010628 replace existing build system with autoconf faceplate ==================== This delta was composed from multiple commits as part of the CVS->Git migration. The checkin message with each commit was inconsistent. The following are the additional commit messages. ==================== so we can fix the file modes ==================== commit withj correct file modes ==================== stuff which got left behind ==================== more stuff which was missed ==================== get this right so build completes ==================== also make these correct (no obj reference) ==================== so autoconf dependancy chain need not change ==================== set correct variable for obsolete buildng ==================== so we can more easily use autoconf'd CC var
2001-06-28 07:44:19 +01:00
configure-cpp-fallback-to-cc-E-20090317 LICENSE IPL10 if we don't find any cpp whatsoever, fall back to $CC -E, or cc -E
2009-03-17 15:44:15 +00:00
AC_PATH_PROGS([PATH_CPP], [cpp], [${CC-cc} -E], [$PATH:/lib:/usr/ccs/lib])
cpp-fixes-20080630 LICENSE BSD When probing in configure for cpp, use the user's PATH first and then the /lib and /usr/ccs/lib directories. Set PATH_CPP instead of CPP, since the latter is just overwritten by Autoconf. Use PATH_CPP by preference in rxgen and when pre-processing assembly, since otherwise newer gcc will treat the input file as linker input and not do anything with it. Don't assume that cpp writes to the second argument; gcc apparently doesn't always do this. Instead, redirect standard output.
2008-07-01 01:00:40 +01:00
AC_SUBST([PATH_CPP])
cf: Set CC before calling AC_PROG_CC On some platforms (HPUX, SOLARIS, AIX), we forcibly set CC or set a default CC, because we must use a specific compiler to build kernel modules, and we specify certain compiler-specific flags. But we do this after AC_PROG_CC has run, which also searches for a compiler to use, and runs a few tests against it. AC_PROG_CC often chooses a different compiler (it prefers gcc if it's available). As a result, some compiler-derived info may be wrong, which can yield confusing results, even breaking the build depending on what the user's PATH is, or what compilers are installed on the system. We can avoid all of this if we move our CC-setting logic to before AC_PROG_CC is called. This is a little tricky, because our logic to set AFS_SYSNAME requires the C compiler, so we must do this before OPENAFS_SYSNAME, and also before AC_USE_SYSTEM_EXTENSIONS, or any other autoconf macro that uses the C compiler. Move our CC-setting logic into a new macro, OPENAFS_PATH_CC, which is separate from OPENAFS_CONFIGURE_COMMON and must be called before OPENAFS_CONFIGURE_COMMON. Add some safeguards to try to detect if AC_PROG_CC is already called to try to prevent future changes from breaking this; this isn't perfect, but it's better than nothing. Change-Id: I7c327df5acc5d1ff701b70825eecaaaab4aa44a8 Reviewed-on: https://gerrit.openafs.org/15456 Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Ben Huntsman <ben@huntsmans.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
2023-05-19 22:53:55 +01:00
OPENAFS_PATH_CC
configure-and-configure-libafs-use-acinclude-as-common-ground-20011008 use a single file for most of both configure scripts ==================== This delta was composed from multiple commits as part of the CVS->Git migration. The checkin message with each commit was inconsistent. The following are the additional commit messages. ==================== except don't require autoconf 2.50
2001-10-09 16:48:25 +01:00
OPENAFS_CONFIGURE_COMMON
autoconf: Split out krb5/gss tests Move our krb5 and GSS-related autoconf tests into their own separate files, in src/cf/krb5.m4 and src/cf/gss.m4. Change-Id: I4202df5d810f2d3942fc4ffb3fd406869f68029b Reviewed-on: https://gerrit.openafs.org/13237 Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: BuildBot <buildbot@rampaginggeek.com>
2018-06-29 20:48:58 +01:00
OPENAFS_KRB5
OPENAFS_GSS
Autoconf: Add GSSAPI autoconf rules Add rules to autodetect the location of a system's GSSAPI libraries, using the gssapi.m4 script from rra-c-util 2.6 Change-Id: Idabb8fdb138a2dac6983aa4d5fd8a2f558ee08be Reviewed-on: http://gerrit.openafs.org/3943 Tested-by: Christof Hanke <christof.hanke@rzg.mpg.de> Reviewed-by: Derrick Brashear <shadow@dementia.org>
2010-09-02 08:44:27 +01:00
build: more configure summary Improved configure summary, including a check for namei fileserver mode. Change-Id: Id5117ae8c27126c56e28eb3ab7f6e8ef7fd0558d Reviewed-on: http://gerrit.openafs.org/10372 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
2013-10-03 17:44:30 +01:00
dnl Checks for summary
OPENAFS_SUMMARY_CHECK_NAMEI
doc: Look in $srcdir for documentation sources In several places, we look for documentation source files in e.g. 'doc/man-pages', 'doc/xml', etc. But if we are running an objdir build, those directories won't exist relative to the current working directory; we need to look in $srcdir to find them. So, if we're running an objdir build, our man pages and other documentation won't be installed. We don't report any error in this case (the relevant steps are just skipped), since building the documentation is optional, in case the doc sources are not present. To fix this, look in $srcdir in the various places that reference doc source files. Fixing the 'for' loops in the 'dest' and 'install' targets in doc/man-pages requires some extra cd'ing around, because $M is used as part of another path in the body of the loop. Change-Id: Ic3c90ab5e64aeefe6235efb6f6ec26080d7b3a70 Reviewed-on: https://gerrit.openafs.org/14622 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
2021-05-12 21:35:01 +01:00
AS_IF([test -d "$srcdir/doc/man-pages"],
build-sys: use AS_IF instead of shell if clause Shell if clauses can cause problems. Change-Id: Ia5fddc78ff43517c37d5abd79f07b35fd18a9058 Reference: http://www.gnu.org/software/autoconf/manual/autoconf-2.67/html_node/Limitations-of-Builtins.html#if Reviewed-on: http://gerrit.openafs.org/10009 Reviewed-by: Simon Wilkinson <simonxwilkinson@gmail.com> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
2013-06-22 18:01:44 +01:00
[MAN_MAKEFILE="doc/man-pages/Makefile doc/man-pages/install-man"],
[MAN_MAKEFILE=])
doc: Look in $srcdir for documentation sources In several places, we look for documentation source files in e.g. 'doc/man-pages', 'doc/xml', etc. But if we are running an objdir build, those directories won't exist relative to the current working directory; we need to look in $srcdir to find them. So, if we're running an objdir build, our man pages and other documentation won't be installed. We don't report any error in this case (the relevant steps are just skipped), since building the documentation is optional, in case the doc sources are not present. To fix this, look in $srcdir in the various places that reference doc source files. Fixing the 'for' loops in the 'dest' and 'install' targets in doc/man-pages requires some extra cd'ing around, because $M is used as part of another path in the body of the loop. Change-Id: Ic3c90ab5e64aeefe6235efb6f6ec26080d7b3a70 Reviewed-on: https://gerrit.openafs.org/14622 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
2021-05-12 21:35:01 +01:00
AS_IF([test -f "$srcdir/doc/xml/AdminGuide/Makefile.in"],
build-sys: use AS_IF instead of shell if clause Shell if clauses can cause problems. Change-Id: Ia5fddc78ff43517c37d5abd79f07b35fd18a9058 Reference: http://www.gnu.org/software/autoconf/manual/autoconf-2.67/html_node/Limitations-of-Builtins.html#if Reviewed-on: http://gerrit.openafs.org/10009 Reviewed-by: Simon Wilkinson <simonxwilkinson@gmail.com> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
2013-06-22 18:01:44 +01:00
[ADMINGUIDE_MAKEFILE="doc/xml/AdminGuide/Makefile"],
[ADMINGUIDE_MAKEFILE=])
doc: Look in $srcdir for documentation sources In several places, we look for documentation source files in e.g. 'doc/man-pages', 'doc/xml', etc. But if we are running an objdir build, those directories won't exist relative to the current working directory; we need to look in $srcdir to find them. So, if we're running an objdir build, our man pages and other documentation won't be installed. We don't report any error in this case (the relevant steps are just skipped), since building the documentation is optional, in case the doc sources are not present. To fix this, look in $srcdir in the various places that reference doc source files. Fixing the 'for' loops in the 'dest' and 'install' targets in doc/man-pages requires some extra cd'ing around, because $M is used as part of another path in the body of the loop. Change-Id: Ic3c90ab5e64aeefe6235efb6f6ec26080d7b3a70 Reviewed-on: https://gerrit.openafs.org/14622 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
2021-05-12 21:35:01 +01:00
AS_IF([test -f "$srcdir/doc/xml/QuickStartUnix/Makefile.in"],
build-sys: use AS_IF instead of shell if clause Shell if clauses can cause problems. Change-Id: Ia5fddc78ff43517c37d5abd79f07b35fd18a9058 Reference: http://www.gnu.org/software/autoconf/manual/autoconf-2.67/html_node/Limitations-of-Builtins.html#if Reviewed-on: http://gerrit.openafs.org/10009 Reviewed-by: Simon Wilkinson <simonxwilkinson@gmail.com> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
2013-06-22 18:01:44 +01:00
[QSUNIX_MAKEFILE="doc/xml/QuickStartUnix/Makefile"],
[QSUNIX_MAKEFILE=])
doc: Look in $srcdir for documentation sources In several places, we look for documentation source files in e.g. 'doc/man-pages', 'doc/xml', etc. But if we are running an objdir build, those directories won't exist relative to the current working directory; we need to look in $srcdir to find them. So, if we're running an objdir build, our man pages and other documentation won't be installed. We don't report any error in this case (the relevant steps are just skipped), since building the documentation is optional, in case the doc sources are not present. To fix this, look in $srcdir in the various places that reference doc source files. Fixing the 'for' loops in the 'dest' and 'install' targets in doc/man-pages requires some extra cd'ing around, because $M is used as part of another path in the body of the loop. Change-Id: Ic3c90ab5e64aeefe6235efb6f6ec26080d7b3a70 Reviewed-on: https://gerrit.openafs.org/14622 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
2021-05-12 21:35:01 +01:00
AS_IF([test -f "$srcdir/doc/xml/UserGuide/Makefile.in"],
build-sys: use AS_IF instead of shell if clause Shell if clauses can cause problems. Change-Id: Ia5fddc78ff43517c37d5abd79f07b35fd18a9058 Reference: http://www.gnu.org/software/autoconf/manual/autoconf-2.67/html_node/Limitations-of-Builtins.html#if Reviewed-on: http://gerrit.openafs.org/10009 Reviewed-by: Simon Wilkinson <simonxwilkinson@gmail.com> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
2013-06-22 18:01:44 +01:00
[USERGUIDE_MAKEFILE="doc/xml/UserGuide/Makefile"],
[USERGUIDE_MAKEFILE=])
doc: Look in $srcdir for documentation sources In several places, we look for documentation source files in e.g. 'doc/man-pages', 'doc/xml', etc. But if we are running an objdir build, those directories won't exist relative to the current working directory; we need to look in $srcdir to find them. So, if we're running an objdir build, our man pages and other documentation won't be installed. We don't report any error in this case (the relevant steps are just skipped), since building the documentation is optional, in case the doc sources are not present. To fix this, look in $srcdir in the various places that reference doc source files. Fixing the 'for' loops in the 'dest' and 'install' targets in doc/man-pages requires some extra cd'ing around, because $M is used as part of another path in the body of the loop. Change-Id: Ic3c90ab5e64aeefe6235efb6f6ec26080d7b3a70 Reviewed-on: https://gerrit.openafs.org/14622 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
2021-05-12 21:35:01 +01:00
AS_IF([test -f "$srcdir/doc/xml/AdminRef/Makefile.in"],
build-sys: use AS_IF instead of shell if clause Shell if clauses can cause problems. Change-Id: Ia5fddc78ff43517c37d5abd79f07b35fd18a9058 Reference: http://www.gnu.org/software/autoconf/manual/autoconf-2.67/html_node/Limitations-of-Builtins.html#if Reviewed-on: http://gerrit.openafs.org/10009 Reviewed-by: Simon Wilkinson <simonxwilkinson@gmail.com> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
2013-06-22 18:01:44 +01:00
[ADMINREF_MAKEFILE="doc/xml/AdminRef/Makefile"],
[ADMINREF_MAKEFILE=])
doc: Look in $srcdir for documentation sources In several places, we look for documentation source files in e.g. 'doc/man-pages', 'doc/xml', etc. But if we are running an objdir build, those directories won't exist relative to the current working directory; we need to look in $srcdir to find them. So, if we're running an objdir build, our man pages and other documentation won't be installed. We don't report any error in this case (the relevant steps are just skipped), since building the documentation is optional, in case the doc sources are not present. To fix this, look in $srcdir in the various places that reference doc source files. Fixing the 'for' loops in the 'dest' and 'install' targets in doc/man-pages requires some extra cd'ing around, because $M is used as part of another path in the body of the loop. Change-Id: Ic3c90ab5e64aeefe6235efb6f6ec26080d7b3a70 Reviewed-on: https://gerrit.openafs.org/14622 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
2021-05-12 21:35:01 +01:00
AS_IF([test -f "$srcdir/doc/xml/mobi-fixup.xsl.in"],
build-sys: use AS_IF instead of shell if clause Shell if clauses can cause problems. Change-Id: Ia5fddc78ff43517c37d5abd79f07b35fd18a9058 Reference: http://www.gnu.org/software/autoconf/manual/autoconf-2.67/html_node/Limitations-of-Builtins.html#if Reviewed-on: http://gerrit.openafs.org/10009 Reviewed-by: Simon Wilkinson <simonxwilkinson@gmail.com> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
2013-06-22 18:01:44 +01:00
[MOBI_FIXUP_XSL="doc/xml/mobi-fixup.xsl"],
[MOBI_FIXUP_XSL=])
doc: Look in $srcdir for documentation sources In several places, we look for documentation source files in e.g. 'doc/man-pages', 'doc/xml', etc. But if we are running an objdir build, those directories won't exist relative to the current working directory; we need to look in $srcdir to find them. So, if we're running an objdir build, our man pages and other documentation won't be installed. We don't report any error in this case (the relevant steps are just skipped), since building the documentation is optional, in case the doc sources are not present. To fix this, look in $srcdir in the various places that reference doc source files. Fixing the 'for' loops in the 'dest' and 'install' targets in doc/man-pages requires some extra cd'ing around, because $M is used as part of another path in the body of the loop. Change-Id: Ic3c90ab5e64aeefe6235efb6f6ec26080d7b3a70 Reviewed-on: https://gerrit.openafs.org/14622 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
2021-05-12 21:35:01 +01:00
AS_IF([test -f "$srcdir/doc/doxygen/Doxyfile.in"],
doxygen: make dox Add an optional make target (make dox) and doxygen configuration to generate doxygen output files. Auto-detect when the doxygen and graphviz dot tools are available. When dot is present, configure doxygen to create dependency graphs. Since the graph generation can take a very long time, a new configure option has been added to override the dot tool auto-detection. To disable the graph generation (even if dot is installed), run configure with the option: --without-dot When graph generation is desired, but graphviz dot is not present in the PATH, specify the path to dot with the configure option --with-dot=<path-to-dot>. The configure summary has been updated to show when doxygen document and graph generation is configured. Thank you Jason Edgecombe for providing the doxygen configuration for OpenAFS. Change-Id: Ie875fc2961877ee76e4c17631bbb95c29ef20b9e Reviewed-on: http://gerrit.openafs.org/10970 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: D Brashear <shadow@your-file-system.com>
2014-03-30 10:53:16 +01:00
[DOXYFILE="doc/doxygen/Doxyfile"],
[DOXYFILE=])
pod-man-pages-20051015 FIXES 19268 add pod generation of man pages
2005-10-15 17:00:57 +01:00
autoconf: updates and cleanup Update autoconf macros to their modern equivalents, according to what the 'autoupdate' tool does. While we're here, remove automake references that aren't being used, and remove the obsolete AC_PROG_LIBTOOL in favor of AFS_LT_INIT. Change-Id: I71066d6d72f8b1d8663e26fec83ae23d7f73f059 Reviewed-on: https://gerrit.openafs.org/12199 Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: BuildBot <buildbot@rampaginggeek.com>
2016-02-29 18:19:01 +00:00
AC_CONFIG_FILES([
build-sys: use m4 quoting consistantly Change-Id: Ie8c5e15fd9ddf521ac74b07ee0e1252b35e7a816 Reviewed-on: http://gerrit.openafs.org/10008 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
2013-06-22 17:28:01 +01:00
Makefile
${MAN_MAKEFILE}
${ADMINGUIDE_MAKEFILE}
${QSUNIX_MAKEFILE}
${USERGUIDE_MAKEFILE}
${ADMINREF_MAKEFILE}
${MOBI_FIXUP_XSL}
doxygen: make dox Add an optional make target (make dox) and doxygen configuration to generate doxygen output files. Auto-detect when the doxygen and graphviz dot tools are available. When dot is present, configure doxygen to create dependency graphs. Since the graph generation can take a very long time, a new configure option has been added to override the dot tool auto-detection. To disable the graph generation (even if dot is installed), run configure with the option: --without-dot When graph generation is desired, but graphviz dot is not present in the PATH, specify the path to dot with the configure option --with-dot=<path-to-dot>. The configure summary has been updated to show when doxygen document and graph generation is configured. Thank you Jason Edgecombe for providing the doxygen configuration for OpenAFS. Change-Id: Ie875fc2961877ee76e4c17631bbb95c29ef20b9e Reviewed-on: http://gerrit.openafs.org/10970 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: D Brashear <shadow@your-file-system.com>
2014-03-30 10:53:16 +01:00
${DOXYFILE}
build-sys: use m4 quoting consistantly Change-Id: Ie8c5e15fd9ddf521ac74b07ee0e1252b35e7a816 Reviewed-on: http://gerrit.openafs.org/10008 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
2013-06-22 17:28:01 +01:00
src/afs/Makefile
src/afsd/Makefile
src/afsmonitor/Makefile
src/aklog/Makefile
src/audit/Makefile
src/auth/Makefile
src/auth/test/Makefile
src/bozo/Makefile
src/bozo/test/Makefile
src/bu_utils/Makefile
src/bubasics/Makefile
src/bucoord/Makefile
src/budb/Makefile
src/tbudb/Makefile
src/butc/Makefile
src/butm/Makefile
src/cmd/Makefile
src/cmd/test/Makefile
src/comerr/Makefile
src/comerr/test/Makefile
src/config/Makefile
src/config/Makefile.config
src/config/Makefile.libtool
src/config/Makefile.lwp
src/config/Makefile.lwptool
src/config/Makefile.pthread
src/config/Makefile.version-CML
src/config/Makefile.version-NOCML
Run ctfconvert/ctfmerge for all objects Commit 88cb536f (autoconf: detect ctf-tools and add ctf to libafs) introduced running ctfconvert and ctfmerge for libafs on Solaris, but didn't add any CTF data for userspace code. This commit causes the same commands to be run for every binary that we build (if the ctf tools are available). To accomplish this, also refactor how we run ctfconvert and ctfmerge. The approach in commit 88cb536f would require us to modify the makefile rule for every executable to run RUN_CTFCONVERT and RUN_CTFMERGE, which is somewhat impractical. So instead in this commit, we modify all of our *_CCRULE and *_LDRULE variables to wrap the compiler invocation with the new CC_WRAPPER script. This means our *RULE variables change from something like this: FOO_CCRULE = $(RUN_CC) $(CC) $(XXX_FLAGS) -o $@ to something like this: FOO_CCRULE = $(RUN_CC) $(CC_WRAPPER) $(CC) $(XXX_FLAGS) -o $@ CC_WRAPPER expands to the script src/config/cc-wrapper, which just runs ctfconvert or ctfmerge on the relevant files after the compiler/linker runs. If the CTF tools are not configured, CC_WRAPPER expands to nothing, to limit our impact on other platforms. This commit was developed in collaboration with mbarbosa@sinenomine.net. Change-Id: Id19ba9d739edc68f01c2db7d5caa20758ec8144a Reviewed-on: https://gerrit.openafs.org/13308 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
2018-09-06 19:42:11 +01:00
src/config/cc-wrapper
build-sys: use m4 quoting consistantly Change-Id: Ie8c5e15fd9ddf521ac74b07ee0e1252b35e7a816 Reviewed-on: http://gerrit.openafs.org/10008 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
2013-06-22 17:28:01 +01:00
src/config/shlib-build
src/config/shlib-install
src/crypto/hcrypto/Makefile
src/crypto/rfc3961/Makefile
src/dir/Makefile
src/dir/test/Makefile
src/dviced/Makefile
src/dvolser/Makefile
src/export/Makefile
src/finale/Makefile
src/fsint/Makefile
src/fsprobe/Makefile
src/gtx/Makefile
src/kauth/Makefile
src/kauth/test/Makefile
src/kopenafs/Makefile
src/libacl/Makefile
src/libacl/test/Makefile
src/libadmin/Makefile
src/libadmin/adminutil/Makefile
src/libadmin/bos/Makefile
src/libadmin/cfg/Makefile
src/libadmin/cfg/test/Makefile
src/libadmin/client/Makefile
src/libadmin/kas/Makefile
src/libadmin/pts/Makefile
src/libadmin/samples/Makefile
src/libadmin/test/Makefile
src/libadmin/vos/Makefile
src/libafs/Makefile.common
src/libafs/MakefileProto.${MKAFS_OSTYPE}
${DARWIN_PLIST}
src/libafsauthent/Makefile
src/libafsrpc/Makefile
src/libuafs/Makefile.common
src/libuafs/MakefileProto.${MKAFS_OSTYPE}
src/log/Makefile
src/log/test/Makefile
src/lwp/Makefile
src/lwp/test/Makefile
src/opr/Makefile
src/packaging/MacOS/OpenAFS-debug.Description.plist
src/packaging/MacOS/OpenAFS-debug.Info.plist
src/packaging/MacOS/OpenAFS.Description.plist
src/packaging/MacOS/OpenAFS.Info.plist
src/packaging/MacOS/OpenAFS.info
src/packaging/MacOS/buildpkg.sh
macos: use pkgbuild to build the package on 10.10/10.11 PackageMaker is no longer part of OS X. As a result, it is not possible to build the package on OS X 10.10 and OS X 10.11 using the existing code. To solve this problem, a new script, along with a couple of new files, are provided. - pkgbuild.sh This script uses the command line tools pkgbuild and productbuild to build the package on OS X 10.10 and OS X 10.11. By default, the package built by this script will not be signed. Optionally, the package might be signed. - Distribution.xml This file is nothing more than an XML file used by productbuild. It is mainly used to configure how the installer will look and behave. - conclusion.txt Contains the text that is displayed by Installer at the end of the installation process. Only used by El Capitan and further. - Uninstall.14.15 This script can be used by OS X 10.10/10.11 users to uninstall OpenAFS. Notes: - This work is based on a patch made by Brandon Allbery <ballbery@sinenomine.net> with fixes and updates from Andrew Deason <adeason@dson.org>. - El Capitan and further prevent us from touching /usr/bin directly. As a result, /opt is used. - If the package is not signed, the user will have to disable the OS X security protections. Otherwise, the client will not work. - Now we have two different scripts to build the package on OS X. For OS X 10.10 and newer versions, pkgbuild.sh will be used. For older versions, the existing buildpkg.sh will be used. Change-Id: If8320666c553b82af450c0263f5e80a00c33e3b8 Reviewed-on: https://gerrit.openafs.org/12239 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
2016-07-15 16:22:11 +01:00
src/packaging/MacOS/pkgbuild.sh
build-sys: use m4 quoting consistantly Change-Id: Ie8c5e15fd9ddf521ac74b07ee0e1252b35e7a816 Reviewed-on: http://gerrit.openafs.org/10008 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
2013-06-22 17:28:01 +01:00
src/pam/Makefile
src/platform/Makefile
src/platform/${MKAFS_OSTYPE}/Makefile
src/platform/DARWIN/growlagent/Makefile
src/procmgmt/Makefile
src/procmgmt/test/Makefile
src/ptserver/Makefile
src/tptserver/Makefile
src/roken/Makefile
src/rx/Makefile
src/rx/bulk.example/Makefile
src/rx/bulktest/Makefile
src/rx/multi.example/Makefile
src/rx/simple.example/Makefile
src/rx/test/Makefile
src/rxdebug/Makefile
src/rxgen/Makefile
Dummy Makefile for rxgk Include a libtool export symbol list for the shared library, which only has the client RPC calls and the NewFooSecurityObject primitives for now, since that's all that's stubbed out. Also connect the rxgk directory up to be buildable from the root, but nothing depends on it yet so it will not be built. Looking ahead, build a libafsrpc_rxgk.la object. Change-Id: I12ddefbdaa1ad4845649e3a32efdeaaa21b5e9b7 Reviewed-on: http://gerrit.openafs.org/10563 Reviewed-by: Chas Williams - CONTRACTOR <chas@cmf.nrl.navy.mil> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: D Brashear <shadow@your-file-system.com>
2013-01-04 21:16:04 +00:00
src/rxgk/Makefile
build-sys: use m4 quoting consistantly Change-Id: Ie8c5e15fd9ddf521ac74b07ee0e1252b35e7a816 Reviewed-on: http://gerrit.openafs.org/10008 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
2013-06-22 17:28:01 +01:00
src/rxkad/Makefile
src/rxkad/test/Makefile
src/rxosd/Makefile
src/rxstat/Makefile
src/scout/Makefile
src/sys/Makefile
src/tbutc/Makefile
src/tests/Makefile
src/tests/run-tests
src/tools/Makefile
src/tools/dumpscan/Makefile
src/tools/rxperf/Makefile
src/tsalvaged/Makefile
src/tsm41/Makefile
src/tvolser/Makefile
src/ubik/Makefile
src/tubik/Makefile
src/update/Makefile
src/usd/Makefile
src/usd/test/Makefile
src/uss/Makefile
src/util/Makefile
src/util/test/Makefile
src/libafscp/Makefile
src/venus/Makefile
src/venus/test/Makefile
src/vfsck/Makefile
src/viced/Makefile
src/vlserver/Makefile
src/tvlserver/Makefile
src/vol/Makefile
src/volser/Makefile
src/xstat/Makefile
src/helper-splint.sh
tests/Makefile
tests/auth/Makefile
tests/cmd/Makefile
tests/common/Makefile
tests/opr/Makefile
tests/rx/Makefile
tests/tap/Makefile
tests/util/Makefile
autoconf: updates and cleanup Update autoconf macros to their modern equivalents, according to what the 'autoupdate' tool does. While we're here, remove automake references that aren't being used, and remove the obsolete AC_PROG_LIBTOOL in favor of AFS_LT_INIT. Change-Id: I71066d6d72f8b1d8663e26fec83ae23d7f73f059 Reviewed-on: https://gerrit.openafs.org/12199 Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: BuildBot <buildbot@rampaginggeek.com>
2016-02-29 18:19:01 +00:00
tests/volser/Makefile])
AC_CONFIG_COMMANDS([default],[chmod a+x src/config/shlib-build
Run ctfconvert/ctfmerge for all objects Commit 88cb536f (autoconf: detect ctf-tools and add ctf to libafs) introduced running ctfconvert and ctfmerge for libafs on Solaris, but didn't add any CTF data for userspace code. This commit causes the same commands to be run for every binary that we build (if the ctf tools are available). To accomplish this, also refactor how we run ctfconvert and ctfmerge. The approach in commit 88cb536f would require us to modify the makefile rule for every executable to run RUN_CTFCONVERT and RUN_CTFMERGE, which is somewhat impractical. So instead in this commit, we modify all of our *_CCRULE and *_LDRULE variables to wrap the compiler invocation with the new CC_WRAPPER script. This means our *RULE variables change from something like this: FOO_CCRULE = $(RUN_CC) $(CC) $(XXX_FLAGS) -o $@ to something like this: FOO_CCRULE = $(RUN_CC) $(CC_WRAPPER) $(CC) $(XXX_FLAGS) -o $@ CC_WRAPPER expands to the script src/config/cc-wrapper, which just runs ctfconvert or ctfmerge on the relevant files after the compiler/linker runs. If the CTF tools are not configured, CC_WRAPPER expands to nothing, to limit our impact on other platforms. This commit was developed in collaboration with mbarbosa@sinenomine.net. Change-Id: Id19ba9d739edc68f01c2db7d5caa20758ec8144a Reviewed-on: https://gerrit.openafs.org/13308 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
2018-09-06 19:42:11 +01:00
chmod a+x src/config/shlib-install
chmod a+x src/config/cc-wrapper],[])
autoconf: updates and cleanup Update autoconf macros to their modern equivalents, according to what the 'autoupdate' tool does. While we're here, remove automake references that aren't being used, and remove the obsolete AC_PROG_LIBTOOL in favor of AFS_LT_INIT. Change-Id: I71066d6d72f8b1d8663e26fec83ae23d7f73f059 Reviewed-on: https://gerrit.openafs.org/12199 Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: BuildBot <buildbot@rampaginggeek.com>
2016-02-29 18:19:01 +00:00
AC_OUTPUT
check curses-libs by configure Presently, the used curses-library are determined by OS. The leads to a build error when no curses-headers are installed. Use configure to test if curses.h or ncurses.h is present. ncurses takes precedence over curses.h. If neither the curses- nor ncurses-libs are available, do not build afsmonitor and scout. A summary at the end of the configure should make this clear to everyone. The variable TXLIBS has been renamed to LIB_curses. Change-Id: I3f661e0b6199be41818dc22149b061e3d599b77f Reviewed-on: http://gerrit.openafs.org/3345 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Derrick Brashear <shadow@dementia.org>
2010-11-21 22:01:53 +00:00
# print a final summary
build: more configure summary Improved configure summary, including a check for namei fileserver mode. Change-Id: Id5117ae8c27126c56e28eb3ab7f6e8ef7fd0558d Reviewed-on: http://gerrit.openafs.org/10372 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
2013-10-03 17:44:30 +01:00
OPENAFS_SUMMARY
Reference in New Issue Copy Permalink