[PATCH 368] New libtoolize --no-warn option.
* libltdl/config/general.m4sh (opt_warning): New option.
(func_warning): Only display a warning message if $opt_warning
is true.
* libtoolize.m4sh (--no-warn): Accept new option.
(func_serial_update_check, func_keyword_update): Use func_warning.
(func_check_macros): Bail out before style issues nags when
$opt_warning is false.
* doc/libtool.texi (Invoking Libtoolize): Document it.
* NEWS: Updated.
---
I hope this will allay Ralf's concerns for users who want to stick
with deprecated macro interfaces, and don't want libtoolize to nag
them to upgrade.
Okay to commit?
ChangeLog | 11 +++
NEWS|2 ++
doc/libtool.texi|6 ++
libltdl/config/general.m4sh |6 +-
libtoolize.m4sh | 14 --
5 files changed, 36 insertions(+), 3 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 5685bda..81a2929 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,16 @@
2008-04-29 Gary V. Vaughan [EMAIL PROTECTED]
+ New libtoolize --no-warn option.
+ * libltdl/config/general.m4sh (opt_warning): New option.
+ (func_warning): Only display a warning message if $opt_warning
+ is true.
+ * libtoolize.m4sh (--no-warn): Accept new option.
+ (func_serial_update_check, func_keyword_update): Use func_warning.
+ (func_check_macros): Bail out before style issues nags when
+ $opt_warning is false.
+ * doc/libtool.texi (Invoking Libtoolize): Document it.
+ * NEWS: Updated.
+
Fix libtoolize test failure with aclocal-1.10.1.
* tests/libtoolize.at
(verbatim aclocal.m4 w/o AC_CONFIG_MACRO_DIR): Force aclocal to
diff --git a/NEWS b/NEWS
index d7579e9..494b863 100644
--- a/NEWS
+++ b/NEWS
@@ -23,6 +23,8 @@ New in 2.2.4: 2008-??-??: CVS version 2.2.3a, Libtool team:
- libtoolize now advises use of `ACLOCAL_AMFLAGS = -I m4' (or
equivalent) where appropriate, and errors out when ACLOCAL_AMFLAGS
names a different directory to AC_CONFIG_MACRO_DIR.
+ - New libtoolize option --no-warn, for users that want to continue to
+use old libtool style without being nagged.
New in 2.2.2: 2008-04-01: CVS version 2.2.1a, Libtool team:
diff --git a/doc/libtool.texi b/doc/libtool.texi
index 5a2bd55..bb1643f 100644
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -2329,6 +2329,12 @@ also specify a subdirectory name here if you are not
using Autoconf
for example. If @command{libtoolize} can't determine the target
directory, @samp{libltdl} is used as the default.
[EMAIL PROTECTED] --no-warn
+Normally, Libtoolize tries to diagnose use of deprecated libtool macros
+and other stylistic issues. If you are deliberately using outdated
+calling conventions, this option prevents Libtoolize from explaining
+how to update your project's Libtool conventions.
+
@item --nonrecursive
If passed in conjunction with @option{--ltdl}, this option will cause
the @command{libltdl} installed by @samp{libtoolize} to be set up for
diff --git a/libltdl/config/general.m4sh b/libltdl/config/general.m4sh
index 29b3d91..53ff5ea 100644
--- a/libltdl/config/general.m4sh
+++ b/libltdl/config/general.m4sh
@@ -153,6 +153,7 @@ opt_dry_run=false
opt_help=false
opt_quiet=false
opt_verbose=false
+opt_warning=:
# func_echo arg...
# Echo program name prefixed message, along with the current mode
@@ -185,7 +186,10 @@ func_error ()
# Echo program name prefixed warning message to standard error.
func_warning ()
{
-$ECHO $progname${mode+: }$mode: warning: ${1+$@} 12
+$opt_warning $ECHO $progname${mode+: }$mode: warning: ${1+$@} 12
+
+# bash bug again:
+:
}
# func_fatal_error arg...
diff --git a/libtoolize.m4sh b/libtoolize.m4sh
index ad024ed..340f46d 100644
--- a/libtoolize.m4sh
+++ b/libtoolize.m4sh
@@ -35,6 +35,7 @@ m4_divert_push([SCRIPT])#! /bin/sh
# -f, --force replace existing files
# -i, --install copy missing auxiliary files
# --ltdl[=DIR] install libltdl sources [default: libltdl]
+# --no-warn don't display warning messages
# --nonrecursiveprepare ltdl for non-recursive make
# -q, --quiet work silently
# --recursive prepare ltdl for recursive make
@@ -153,6 +154,8 @@ configure_ac=configure.in
fi
;;
+ --no-warn) opt_warning=false ;;
+
--nonrecursive|--non-recursive)
ltdl_mode=nonrecursive
;;
@@ -743,7 +746,7 @@ func_serial_update_check ()
if test -f $my_destfile; then
test X$my_src_serial = X0 {
-func_error warning: no serial number on \`$my_srcfile', not copying.
+func_warning no serial number on \`$my_srcfile', not copying.
return
}
@@ -904,7 +907,7 @@ func_keyword_update ()
if test -f $my_destfile; then
my_src_serial=`$SED -e $my_sed_script $my_srcfile`
test -z $my_src_serial {
-func_error
Re: [PATCH 368] New libtoolize --no-warn option.
On Tue, 29 Apr 2008, Gary V. Vaughan wrote: I hope this will allay Ralf's concerns for users who want to stick with deprecated macro interfaces, and don't want libtoolize to nag them to upgrade. Okay to commit? The immediate concern I have with this approach (--no-warn) is that the main reason for using it is to make use of a package's autogen.sh (or whatever) more pleasing. However, since old libtoolize does not support the option, it is likely to simply quit. As a result, --no-warn can not safely be used if it is possible that some developers are using old libtoolize while others are using modern libtoolize. That makes it almost worthless. This is one rare case where providing the option via an evironment variable is safer. Then the many autogen.sh can set an environment variable to hush the warnings. Did you consider that? Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: [PATCH 368 bis] New libtoolize --no-warn option and LIBTOOLIZE_OPTIONS parsing.
On Tue, 29 Apr 2008, Gary V. Vaughan wrote: I hope this will allay Bob's concerns for users who want to stick with deprecated macro interfaces, and don't want libtoolize to nag them to upgrade, even while some stubborn project developers refuse to upgrade to a libtool release that will help them do that. :-p Okay to push? This is definitely better, but there are still a few concerns. The text describing New features lists several libtool options which may be passed via the environment variable, but not this new --no-warn option. The term bailed out may be confusing to people who are not primarily english speakers. It seems best to use terms (e.g. quit) which are straightforward dictionary translations. If you fix these few issues, then the patch seems ok to me. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Patch for cygwin: autoupdate and objdump
Ralf Wildenhues wrote: 2008-04-19 Charles Wilson ... Yaakov Selkowitz ... * libltdl/m4/libtool.m4 (_LT_DECL_OBJDUMP): new macro ensures that $OBJDUMP is always defined sanely. (_LT_SYS_DYNAMIC_LINKER): call it. (_LT_CHECK_MAGIC_METHOD): call it. (AU_DEFUN[AC_PROG_LIBTOOL]): replace AU_ALIAS[AC_PROG_LIBTOOL]; call both LT_INIT and LT_OUTPUT. Warn user to remove LT_OUTPUT if not necessary for their package. (AU_ALIAS[AM_PROG_LIBTOOL]): direct to AC_PROG_LIBTOOL above, not LT_INIT. Ping? It's been more than 72 hours, but I still don't have git fully working, so I'd appreciate it if somebody could check this in for me. The OBJDUMP parts of this are ok, and I will check them in tomorrow. The rest has received negative feedback here: http://thread.gmane.org/gmane.comp.gnu.libtool.general/9238/focus=9267 Ping on OBJDUMP parts? -- Chuck
Re: [PATCH 368 bis] New libtoolize --no-warn option and LIBTOOLIZE_OPTIONS parsing.
Hi Bob, Thanks for the review. On 29 Apr 2008, at 19:34, Bob Friesenhahn wrote: On Tue, 29 Apr 2008, Gary V. Vaughan wrote: I hope this will allay Bob's concerns for users who want to stick with deprecated macro interfaces, and don't want libtoolize to nag them to upgrade, even while some stubborn project developers refuse to upgrade to a libtool release that will help them do that. :-p Okay to push? This is definitely better, but there are still a few concerns. The text describing New features lists several libtool options which may be passed via the environment variable, but not this new --no- warn option. --no-warn is mentioned in the ChangeLog, NEWS and several times in the texinfo documentation including an example. I can't see where you're missing it from... The term bailed out may be confusing to people who are not primarily english speakers. It seems best to use terms (e.g. quit) which are straightforward dictionary translations. Okay, done. If you fix these few issues, then the patch seems ok to me. I'll push presently. Cheers, Gary -- ())_. Email me: [EMAIL PROTECTED] ( '/ Read my blog: http://blog.azazil.net / )= ...and my book: http://sources.redhat.com/autobook `(_~)_ PGP.sig Description: This is a digitally signed message part
Re: Patch for cygwin: silence cwrapper compilation warnings
Charles Wilson wrote:
2008-04-25 Charles Wilson ...
Ensure cwrapper compiles without warnings under -std=c99:
* libltdl/config/ltmain.m4sh (func_emit_wrapper_part1):
new function.
(func_emit_wrapper_part2): new function.
(func_emit_wrapper): delegate to new functions.
(func_emit_cwrapperexe_src) [__CYGWIN__ __STRICT_ANSI__]:
ensure realpath is declared.
(func_emit_cwrapperexe_src): declare two different strings
to each hold part of the wrapper script content. Initialize
using new func_emit_wrapper_partX functions.
(func_emit_cwrapperexe_src) [main]: when emitting wrapper
script content, use both strings.
However, this bit in the posted patch, in func_emit_wrapper():
+ func_emit_wrapper_part1 ${func_emit_wrapper_arg1}
+ func_emit_wrapper_part2 ${func_emit_wrapper_arg2}
should really be
+ func_emit_wrapper_part1 ${func_emit_wrapper_arg1}
+ func_emit_wrapper_part2 ${func_emit_wrapper_arg1}
because func_emit_wrapper() only has *arg1 and should pass that argument
on to both of the func_emit_wrapper_part*() sub-functions.
Okay for push, with the above change and rebasing?
BTW, what's the normal procedure after rebasing your topic branch, and
pulling into (local) master [and, according to Jim's suggestions on
gnulib mailing list, finally adding your commit info to the ChangeLog, and
git-add ChangeLog
git commit --amend -e
]?
On CVS, instead of 'cvs commit' you'd do 'clcommit'
On GIT, instead of 'git-push' you do...?
--
Chuck
Re: [Patch] cwrapper invokes target directly
Charles Wilson wrote: 2008-04-26 Charles Wilson ... [mingw|cygwin] Modify cwrapper to invoke target directly. * libltdl/config/ltmain.m4sh (func_to_native_path): new function. If $host is mingw, and $build is mingw or cygwin, convert path to mingw native format. (func_to_native_pathlist): new function. Ditto, for :-separated pathlists. (func_emit_cwrapperexe_src) [__CYGWIN__ __STRICT_ANSI__]: ensure putenv and setenv are declared. Define HAVE_SETENV. (func_emit_cwrapperexe_src) [main]: add new constants to hold desired PATH settings; initialize and convert to native mingw format using functions above. Add new command-line options --lt-env-set, --lt-env-prepend, and --lt-env-append. No longer emit wrapper script as integral part of launching child. Remove support for (now) unnecessary $TARGETSHELL. Exec actual target executable directly. (func_emit_cwrapperexe_src) [lt_setenv]: new function. (func_emit_cwrapperexe_src) [lt_extend_str]: new function. (func_emit_cwrapperexe_src) [lt_split_name_value]: new function. (func_emit_cwrapperexe_src) [lt_opt_process_env_set]: new function. (func_emit_cwrapperexe_src) [lt_opt_process_env_prepend]: new function. (func_emit_cwrapperexe_src) [lt_opt_process_env_append]: new function. (func_emit_cwrapperexe_src) [lt_update_exe_path]: new function. (func_emit_cwrapperexe_src) [lt_update_lib_path]: new function. Ping? Okay for push? *Any* comments at all? -- Chuck
Re: [Patch] cwrapper invokes target directly
On Tue, 29 Apr 2008, Charles Wilson wrote: Ping? Okay for push? *Any* comments at all? I forgot that you have the ability to do this by yourself. Ralf says that he has been busy and will soon be unavailable for a week or two. Meanwhile, Gary is wanting to cut a new release on (or before) May 3rd. Since we are trying to pop out new libtool releases a lot more often, can we defer your patch until after Gary cuts the forthcoming release? That way the patch has at least a whole month to be inspected and thoroughly tested before the subsequent release. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: [Patch] cwrapper invokes target directly
Bob Friesenhahn wrote: I forgot that you have the ability to do this by yourself. Ralf says that he has been busy and will soon be unavailable for a week or two. Meanwhile, Gary is wanting to cut a new release on (or before) May 3rd. Since we are trying to pop out new libtool releases a lot more often, can we defer your patch until after Gary cuts the forthcoming release? That way the patch has at least a whole month to be inspected and thoroughly tested before the subsequent release. Sure, I can wait. /I'm/ not trying to build in a cross-compile setup for mingw $host, so 2.2.2 works just fine for me. If I can get some feedback on the '*_with_wine.sh' script I could update the patch to also support $build=some_unixy_platform_with_wine and $host=mingw. (The script in question is the #3 attachment to the message that started this thread. It's here http://lists.gnu.org/archive/html/libtool-patches/2008-04/msg00164.html and http://article.gmane.org/gmane.comp.gnu.libtool.patches/8429 but in both cases, the attachments all run together...) On another note, I think the $OBJDUMP part of this: http://lists.gnu.org/archive/html/libtool-patches/2008-04/msg00098.html (that is, all but the first hunk) and this: http://lists.gnu.org/archive/html/libtool-patches/2008-04/msg00161.html with the one-liner change mentioned here http://lists.gnu.org/archive/html/libtool-patches/2008-04/msg00163.html are suitable for 2.2.4 and it'd be nice to get them in. -- Chuck
