Re: libtool --silent based on MAKEFLAGS?

2004-12-12 Thread Peter O'Gorman
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ralf Wildenhues wrote:
| So, how about this?  Let's have Automake include $(LIBTOOLFLAGS) in
| their libtool invocation.  The user can then use
|   LIBTOOLFLAGS=--silent
|
| What do you think?
Forgetting the rest of you mail for the moment, why involve automake? Is it
a bad idea to have libtool look for a LIBTOOLFLAGS environment variable?
Peter
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iQCVAwUBQbxHuriDAg3OZTLPAQKmbgP/YzGWuktns3Pci63Sfw+SuP41kX9lkdAU
TJeAfW9HCcYOIVpJVSPXBhGQqe0OsiYyCBc7Gyq6LThk3H3Zu3HMvGjiVHnpFOWq
mA0USTClZFYO1A9+7UWFf8GdoLs9HblSjEONfH3m6FXtB/7wiIjL33X3umK+1Y8I
8KKlO9GwBEY=
=2WAv
-END PGP SIGNATURE-
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool


Re: libtool --silent based on MAKEFLAGS?

2004-12-12 Thread Alexandre Duret-Lutz
 Ralf == Ralf Wildenhues [EMAIL PROTECTED] writes:

[...]

 Ralf So, how about this?  Let's have Automake include $(LIBTOOLFLAGS) in
 Ralf their libtool invocation.  The user can then use
 Ralf LIBTOOLFLAGS=--silent
 Ralf at either configure or make time.  This approach is Automake-centric,
 Ralf but other buildtools can do similar.

Sounds sensible to me.  People have also asked this to specify
--preserve-dup-deps, and --tag=FOO in cases Automake cannot
guess it.

Let's make it `$(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS)' with 
`$(AM_LIBTOOLFLAGS)' replaced by `libfoo_la_LIBTOOLFLAGS' if it exists.

I'm working on this right now.
-- 
Alexandre Duret-Lutz



___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool


Re: libtool --silent based on MAKEFLAGS?

2004-12-12 Thread Ralf Wildenhues
* Peter O'Gorman wrote on Sun, Dec 12, 2004 at 02:29:30PM CET:
 Ralf Wildenhues wrote:
 
 | So, how about this?  Let's have Automake include $(LIBTOOLFLAGS) in
 | their libtool invocation.  The user can then use
 |   LIBTOOLFLAGS=--silent
 |
 | What do you think?
 
 Forgetting the rest of you mail for the moment, why involve automake? Is it
 a bad idea to have libtool look for a LIBTOOLFLAGS environment variable?

IMHO yes.  From libtool's point of view, there's nothing needed besides
the command line.  Other build tools can easily add support for this as
well.  One additional bonus is you don't have to worry about precedence
-- it's the job of the tool calling libtool.

Just my opinion (and by no means set in stone).

Regards,
Ralf (please remember the rest of my mail eventually)


___
http://lists.gnu.org/mailman/listinfo/libtool


Re: libtool --silent based on MAKEFLAGS?

2004-12-10 Thread Ralf Wildenhues
Hi Martin,

* Martin Waitz wrote on Fri, Dec 10, 2004 at 02:50:42PM CET:
 
 next request:
 
 could libtool take a look at MAKEFLAGS and automatically use --silent
 mode when 's' is included in the make flags?

That sounds like a good idea -- in principle.

 At the moment I'm unconditionally using libtool --silent to make
 'make -s' usable. It would be nicer if libtool would handle that
 automatically.
 
 An alternative would be to implement short options (make -s an alias
 to --silent and ignore all other short options) and use
 'libtool -$(MAKEFLAGS)', but I don't really like that.

Nope.  MAKEFLAGS can have more than one possible format (either the
options like given on the command line, or just the letters
corresponding to those options) according to XSI.  GNU Make does the
latter and also adds possible long options and other variable settings
afterwards, so we want to treat that correctly as well.

I'm not sure how to reliably distinguish between both forms without any
forking.  But here's a try with just a subshell. 

Because the user has to be able to override this, we now need an option
to undo this.  And we need to adjust some tests to use this, because
they check the output of libtool.

Two things I'm unsure about:
- whether `-v|--verbose' was or is in use w.r.t libtool.  Should I
  use that rather than --no-silent?
- interaction between `-n|--dry-run' and silence.
  Should --dry-run imply --no-silent?
  (One could imagine just trying to syntax-check with --dry-run
  --silent; in some future version of libtool).

OK to apply (to HEAD only, this is a new feature)?

Are there any packages that rely on the old behavior?

Regards,
Ralf

* config/ltmain.m4sh (func_make_s): New function to detect
`make -s'.  Use before parsing the command line so that new
option `--no-silent' can override it.
* NEWS, doc/libtool.texi (Invoking libtool): Mention it.
* tests/link.test, tests/link-2.test, tests/objectlist.test,
 tests/quote.test: Adjust to use --no-silent so `make -s check'
does the right thing.


Index: NEWS
===
RCS file: /cvsroot/libtool/libtool/NEWS,v
retrieving revision 1.175
diff -u -r1.175 NEWS
--- NEWS29 Nov 2004 21:18:26 -  1.175
+++ NEWS10 Dec 2004 16:36:09 -
@@ -6,6 +6,7 @@
 * Fix libltdl on static platforms.
 * Support for linux-dietlibc (`diet' as well as `diet-dyn', separately).
 * Shell optimizations which break use of the stdin file descriptor in libtool.
+* libtool now honors `make -s' (MAKEFLAGS).  Use --no-silent to override.
 
 New in 1.9h: 2004-??-??; CVS version 1.9g, Libtool team:
 * Libtool versions can now be parallel installed, except that only one
Index: config/ltmain.m4sh
===
RCS file: /cvsroot/libtool/libtool/config/ltmain.m4sh,v
retrieving revision 1.34
diff -u -r1.34 ltmain.m4sh
--- config/ltmain.m4sh  9 Dec 2004 17:59:15 -   1.34
+++ config/ltmain.m4sh  10 Dec 2004 16:36:09 -
@@ -38,6 +38,7 @@
 # --mode=MODE  use operation mode MODE
 # --preserve-dup-deps  don't remove duplicate dependency libraries
 # --quiet, --silentdon't print informational messages
+# --no-silent  print informational messages (default)
 # --tag=TAGuse configuration variables from tag TAG
 # --versionprint version information
 # -h, --help   print short or long help message
@@ -393,6 +394,24 @@
 exit $EXIT_SUCCESS
 }
 
+func_make_silent ()
+{
+  ( has_s=false
+  set x $MAKEFLAGS
+  case $2 in
+s* | [^-]*s* ) # single-letter options within the first word (eg. GNU Make)
+has_s=:
+;;
+  esac
+  case $MAKEFLAGS in
+-s | *\ -s | -s\ * | *\ -s\ * ) # hyphenated options (eg. BSD Make)
+has_s=:
+;;
+  esac
+  $has_s )  opt_silent=:
+  : # work around bash bug
+}
+
 # Parse options once, thoroughly.  This comes as soon as possible in
 # the script to make things like `libtool --version' happen quickly.
 {
@@ -427,6 +446,8 @@
 ;;
   esac
 
+  func_make_silent # set first to allow cmdline override
+
   # Parse non-mode specific arguments:
   while test $# -gt 0; do
 opt=$1
@@ -479,6 +500,10 @@
opt_silent=:
;;
 
+  --no-silent)  preserve_args=$preserve_args $opt
+   opt_silent=false
+   ;;
+
   --tag)   test $# -eq 0  func_missing_arg $opt  break
preserve_args=$preserve_args $opt $1
func_enable_tag $1# tagname is set here
Index: doc/libtool.texi
===
RCS file: /cvsroot/libtool/libtool/doc/libtool.texi,v
retrieving revision 1.185
diff -u -r1.185 libtool.texi
--- doc/libtool.texi23 Nov 2004 09:37:06 -  1.185
+++ doc/libtool.texi10 Dec 2004 

Re: libtool --silent based on MAKEFLAGS?

2004-12-10 Thread Bob Friesenhahn
On Sat, 11 Dec 2004, Peter O'Gorman wrote:
Ralf Wildenhues wrote:
Hi Martin,
* Martin Waitz wrote on Fri, Dec 10, 2004 at 02:50:42PM CET:
next request:
could libtool take a look at MAKEFLAGS and automatically use --silent
mode when 's' is included in the make flags?
That sounds like a good idea -- in principle.
I don't really like this idea, no real reason, just that looking at some
other program's environment variable feels wrong.
I haven't even looked at your patch, and please don't consider this a veto,
just want to know if there is any third alternative.
I am pretty happy with my configure-based hack.  It assumes that 
libtool will work as expected so it is not necessary for the user to 
see everything by default.  Unfortunately, when things go wrong, it is 
necessary to reconfigure in order to debug libtool.

The MAKEFLAGS approach makes an assumption.  It assumes that libtool 
is being driven by 'make' rather than some other tool like Jam, Ant, 
an IDE, or some other alternative build tool.  There is no requirement 
for a project using libtool to also use 'make'.

Bob
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool


Re: libtool --silent based on MAKEFLAGS?

2004-12-10 Thread Peter O'Gorman
Ralf Wildenhues wrote:
Hi Martin,
* Martin Waitz wrote on Fri, Dec 10, 2004 at 02:50:42PM CET:
next request:
could libtool take a look at MAKEFLAGS and automatically use --silent
mode when 's' is included in the make flags?

That sounds like a good idea -- in principle.
I don't really like this idea, no real reason, just that looking at some
other program's environment variable feels wrong.
I haven't even looked at your patch, and please don't consider this a veto,
just want to know if there is any third alternative.
Peter
--
Peter O'Gorman - http://www.pogma.com
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool


Re: libtool --silent based on MAKEFLAGS?

2004-12-10 Thread Bob Friesenhahn
On Fri, 10 Dec 2004, Martin Waitz wrote:
hoi :)
next request:
could libtool take a look at MAKEFLAGS and automatically use --silent
mode when 's' is included in the make flags?
At the moment I'm unconditionally using libtool --silent to make
'make -s' usable. It would be nicer if libtool would handle that
automatically.
An alternative would be to implement short options (make -s an alias
to --silent and ignore all other short options) and use
'libtool -$(MAKEFLAGS)', but I don't really like that.
As a workaround, I use this in my configure script.  The default is 
then silent:

# Enable verbose output from libtool (enable libtool's default)
AC_ARG_ENABLE(libtool-verbose,
  [  --enable-libtool-verbose enable verbose libtool output 
(default disabled)],
  [with_libtool_verbose=$enableval],
  [with_libtool_verbose='no'])
if test $with_libtool_verbose = 'no'
then
  LIBTOOL=$LIBTOOL --silent
fi

Bob
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool