How to use echo
OK to apply (HEAD, branch-2-0)? (I do realize that my notation is kind of inconsistent -- should I write printf %s\\n instead?) Regards, Ralf Index: HACKING === RCS file: /cvsroot/libtool/libtool/HACKING,v retrieving revision 1.12 diff -u -r1.12 HACKING --- HACKING 1 Feb 2005 07:34:33 - 1.12 +++ HACKING 25 Mar 2005 09:28:02 - @@ -226,7 +226,23 @@ functions should begin indented by 4 spaces. -8. Abstraction layers in libltdl +8. Editing `.m4' Files +== + +* Be careful with both `echo' and `$ECHO'. As the latter may be one of +echo +print -r +printf %s\n +$CONFIG_SHELL $0 --fallback-echo + it may not have more than one argument, its value may not be eval'ed + and the argument may not start with a `-'. As a rule of thumb, use +echo ..for literal (constant) strings without leading + hyphen and no backslashes within, +$ECHO .. for strings without leading hyphen, +$ECHO .. | $Xsed otherwise. + + +9. Abstraction layers in libltdl * The libltdl API uses a layered approach to differentiate internal and @@ -310,7 +326,7 @@ lt__private.h -9. Release Procedure +10. Release Procedure * If you are a libtool maintainer, but have not yet registered your @@ -397,7 +413,7 @@ -10. Alpha release note template +11. Alpha release note template === To: libtool@gnu.org, autotools-announce@gnu.org @@ -470,7 +486,7 @@ -11. Full release note template +12. Full release note template == To: info-gnu@gnu.org
Re: simplify libtoolize path fiddling [libtool--gary--1.0--patch-11]
Hi Gary, * Gary V. Vaughan wrote on Thu, Mar 24, 2005 at 06:16:33PM CET: Okay to commit? Most of the hair introduced ostensibly to enable testing of uninstalled libtoolize isn't necessary if we allow overriding of the libtool master copy directory: * configure.ac (pkvmacrodir): No need to substitute this. * Makefile.am (edit): No need to substitute pkgvmacrodir. (dist_pkgvdata_DATA): Use nobase_ prefix so that these files are installed to $(pkgvdatadir)/config. Not sure if this will upset people as yet-another backwards incompatibility. Not if they use `libtoolize', that is. (pkgvmacro_DATA): Renamed to... (nobase_pkgvdata_DATA): ...this, so that files are installed to $(pkgvdatadir)/m4. So this tells me your patch is against HEAD. Please write that upfront so I don't need to kill my branch-2-0 tree. Thank you. (I previously thought libtool--gary--1.0 was branch-2-0 and libtool--devo was HEAD?) This is also still pending the decision whether to put the m4 files back to where aclocal can find them, right? Will that break all your nice simplifications then? (install-data-hook): Adjust. * libtoolize.m4sh: Remove -I processing. (func_filename_path_search): No longer required without -I. Adjust all callers. (pkgvltdldirs, pkgvmacrodirs): Deleted. (pkgvdatadir): Allow overriding from the environment so that we can write tests for uninstalled libtoolize. (func_serial_update, func_ltmain_update, func_config_update): Rename srcdirs parameter to srcdir, and don't call the path_search function anymore. Adjust all callers. (--install): Don't blindly copy all config files. It would be nice to see a test case so that one could verify that all of this works. Other than above, I noticed that a `make uninstall' leaves quite a number of files behind -- all of libltdl -- but that is orthogonal to this patch. Regards, Ralf
Re: simplify libtoolize path fiddling [libtool--gary--1.0--patch-11]
Ralf Wildenhues wrote: Hi Gary, Hallo Ralf, Thanks again for the review! * Gary V. Vaughan wrote on Thu, Mar 24, 2005 at 06:16:33PM CET: Okay to commit? Most of the hair introduced ostensibly to enable testing of uninstalled libtoolize isn't necessary if we allow overriding of the libtool master copy directory: * configure.ac (pkvmacrodir): No need to substitute this. * Makefile.am (edit): No need to substitute pkgvmacrodir. (dist_pkgvdata_DATA): Use nobase_ prefix so that these files are installed to $(pkgvdatadir)/config. Not sure if this will upset people as yet-another backwards incompatibility. Not if they use `libtoolize', that is. Hmm good point. But are we trying to support mismatched libtoolize vs pkgdatadir? It wouldn't be difficult to fall back from $pkgvdatadir/config to $pkgvdatadir if config is missing, but that is more hair, which I'm trying to shave off atm ;-) My feeling is that if people expect to use mismatched installations of libtool, that it would be better for us to notice, and error out rather than introduce lots of code to support mismatched installations. The results of running any libtoolize (against it's own installed files) in the source tree is not changed by this patch. (pkgvmacro_DATA): Renamed to... (nobase_pkgvdata_DATA): ...this, so that files are installed to $(pkgvdatadir)/m4. So this tells me your patch is against HEAD. Please write that upfront so I don't need to kill my branch-2-0 tree. Thank you. (I previously thought libtool--gary--1.0 was branch-2-0 and libtool--devo was HEAD?) Oh, sorry. Arch terminology category--branch--version, where I'm using version to denote which CVS branch and branch to denote the arch branch. libtool--devo--1.0 is HEAD, libtool--release--2.0 is branch-2-0, and libtool--gary--1.0 is my scratchpad branch from HEAD. If I wanted to do development on branch-2-0 I'd create libtool--gary--2.0. I'll be explicit in future though. My bad. This is also still pending the decision whether to put the m4 files back to where aclocal can find them, right? Will that break all your nice simplifications then? Yes it is pending, but I've decided to go with consensus and revert the parallel installations patch. I just haven't done it yet. No, it won't break the simplifications at all, although some of the same lines in libtoolize.m4sh will be touched again. (install-data-hook): Adjust. * libtoolize.m4sh: Remove -I processing. (func_filename_path_search): No longer required without -I. Adjust all callers. (pkgvltdldirs, pkgvmacrodirs): Deleted. (pkgvdatadir): Allow overriding from the environment so that we can write tests for uninstalled libtoolize. (func_serial_update, func_ltmain_update, func_config_update): Rename srcdirs parameter to srcdir, and don't call the path_search function anymore. Adjust all callers. (--install): Don't blindly copy all config files. It would be nice to see a test case so that one could verify that all of this works. Absolutely. But I can't write any tests for libtoolize until there is a way of running libtoolize out of the build tree. Originally I introduced the -I flag for that, but now this patch allows a test to override pkgvdatadir. If this one goes in, I'll start enhancing the testsuite to cover libtoolize too. Other than above, I noticed that a `make uninstall' leaves quite a number of files behind -- all of libltdl -- but that is orthogonal to this patch. Thanks, I hadn't noticed that. Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature
Our IT Services
Title: Our IT Services Hi , I hope things are going well at your company! How can I help with your current need for IT Consultants at your company? CGT Consulting provides highly specialized contract consultants for immediate results. We maintain a base of deployable consultants in the areas of ERP, CRM, Wireless and Web-based technology, including .NET. In addition, CGT draws from an immense in-house database of over 1 Million outside candidates. We are committed to fast and effective technology services paired with a unique corporate philosophy of Cost-Conscious Consulting. How can I be of service to you, at your company ? As an example, we have Consultants in the area of Project Managers, Analysts, Developer, QA, Network ... etc Thank you. Nick CGT Consulting Inc. Tel: (714) 572-1055 Emailed to: libtool-patches@gnu.org Anti-SPAM Policy Disclaimer: mailto:[EMAIL PROTECTED] Under Bill s.1618 Title III passed by the 105th U. S. Congress, mail cannot be considered Spam as long as we include contact information and a remove link for removal from our mailing list. If this e-mail is unsolicited, please accept our apologies and click on the following removal link: mailto:[EMAIL PROTECTED] or reply back with REMOVE in the SUBJECT with this email address: libtool-patches@gnu.org
Notification of Limited Account Access (Routing Code: B213-K007-W566-D2560)
Title: Untitled Document As part of our security measures, we regularly screen activity in the PayPal system. We recently noticed the following issue on your account: We recently received a report of unauthorized credit card use associated with this account. As a precaution, we have limited access to your PayPal account in order to protect against future unauthorized transactions. Case ID Number: PP-091-233-629 For your protection, we have limited access to your account until additional security measures can be completed. We apologize for any inconvenience this may cause. To review your account and some or all of the information that PayPal used to make its decision to limit your account access, please visit the Resolution Center by following the link below: https://www.paypal.com/cgi-bin/webscr?cmd=login-run If, after reviewing your account information, you seek further clarification regarding your account access, please contact PayPal by visiting the Help Center and clicking "Contact Us" We thank you for your prompt attention to this matter. Please understand that this is a security measure intended to help protect you and your account. We apologize for any inconvenience. Sincerely, PayPal Account Review Department PayPal Email ID PP545 Accounts Management as outlined in our User Management , Paypal will periodically send you information about site changes and enhancements Visit our Privacy Policy and User Agreement if you have any questions : http://www.paypal.com/cgi-bin/webscr?cmd=p/gen/ua/policy_privacy-outside
