Re: AC_INIT translates PACKAGE to lower case
Am Sam, 2002-02-02 um 08.34 schrieb Tom Tromey: > > "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes: > > Tom> Automake used PACKAGE with a specific meaning for years. It is > Tom> unfortunate that Autoconf has chosen to use the same name with a > Tom> different meaning. But I don't wish to belabor this point. > > Of course, it would be idiotic for me to belabor this point, since it > is factually incorrect. Autoconf doesn't define PACKAGE at all. Wow. Thanks for pointing this out - I had missed that fact and it's good to know that others weren't aware about this, too. You are right, it's automake's init.m4 which sets it from AC_PACKAGE_TARNAME, .. [_AM_SET_OPTIONS([$1])dnl AC_SUBST([PACKAGE], [AC_PACKAGE_TARNAME])dnl AC_SUBST([VERSION], [AC_PACKAGE_VERSION])])dnl .. > Tom> If we elect not to do this then we must add a warning to the manual > Tom> saying that the obvious change is incorrect. > > I think I'll do this. Plus I'll have the PACKAGE define use > PACKAGE_TARNAME. AFAIS, it already does so. => Autoconf's lowercasing of AC_PACKAGE_TARNAME from the first argument of AC_INIT and having been documented as PACKAGE in autoconf's manual is the actual origin of the problem and has broken backward compatibility of automake's PACKAGE However, there is another issue lurking: The 3rd parameter of AC_INIT_AUTOMAKE (Suppress AC_DEFINE-ing of PACKAGE and VERSION) Ralf
AM_CONDITIONAL and config.status
I make heavy use of AM_CONDITIONAL in my Makefile.ams, mainly for conditional compiliation of stuff. This now works really well with automake 1.5 (it required nasty hacks with 1.4). My question is, although I use if CONDITIONAL FOO else BAR endif in Makefile.am, and this becomes @CONDITIONAL_TRUE@FOO @CONDITIONAL_FALSE@BAR in Makefile.in, is it safe to use this format in my own .in files (e.g. po/POTFILES.in), or will the format used for the conditionals in .in files change at a future date? What I need to do is have lines conditionally included, as some are conditionally distributed. @GIMP_SOURCE_FALSE@# CUPS sources @GIMP_SOURCE_FALSE@src/cups/genppd.c @GIMP_SOURCE_FALSE@# Foomatic-related sources @GIMP_SOURCE_FALSE@src/foomatic/printer_options.c or do they need a preceding _TRUE line to match each false one? Also, would it be possible in the future to allow the following expansion by automake?: if COND FOO BAR BAZ else BAD endif and output the following: @COND_TRUE@FOO @COND_TRUE@BAR @COND_TRUE@BAZ @COND_FALSE@BAD which would enable multiple lines to be enclosed within conditionals, and therefore whole rules can be made conditional (it is currently possible to wrap just the target:deps line in a conditional, but this breaks non-GNU makes, which panic on seeing commands in the middle of nowhere). Being able to use 'ifndef' would also be another nice addition, or has this already been done (I possibly remember this being mentioned). Regards, Roger -- Roger Leigh ** Registration Number: 151826, http://counter.li.org ** Need Epson Stylus Utilities? http://gimp-print.sourceforge.net/ GPG Public Key: 0x25BFB848 available on public keyservers msg04533/pgp0.pgp Description: PGP signature
Re: AC_INIT translates PACKAGE to lower case
> "Ralf" == Ralf Corsepius <[EMAIL PROTECTED]> writes: Ralf> The 3rd parameter of AC_INIT_AUTOMAKE (Suppress AC_DEFINE-ing of Ralf> PACKAGE and VERSION) We already handle this. The new way to use AM_INIT_AUTOMAKE is to pass automake options to it. One of the options is "no-define", which acts like the old 3rd parameter to AC_INIT_AUTOMAKE. It was a mistake, all those years ago, not to require a specific word to be put there. Tom
Re: AM_CONDITIONAL and config.status
> "Roger" == Roger Leigh <[EMAIL PROTECTED]> writes: Roger> in Makefile.in, is it safe to use this format in my own .in files (e.g. Roger> po/POTFILES.in), or will the format used for the conditionals in .in Roger> files change at a future date? What I need to do is have lines Roger> conditionally included, as some are conditionally distributed. Conditionals don't work they way you seem to think they do. The @FOO_TRUE@ is rewritten to either `' (empty string) or `#' (make comment) by configure. No line is omitted from the generated Makefile. My recommendation is not to rely on the implementation of conditionals. It isn't something we have ever documented. We might actually change it at some point; for instance we might be able to get better performance from config.status if we change how conditionals are implemented. Roger> if COND Roger> FOO Roger> BAR Roger> BAZ Roger> else Roger> BAD Roger> endif I read this example but I don't understand how it differs from what we already do. Right now you can enclose all kinds of stuff in a single conditional. What you can't do is have a conditional that starts or ends in the middle of a rule or macro definition. Roger> Being able to use 'ifndef' would also be another nice addition, Roger> or has this already been done (I possibly remember this being Roger> mentioned). You can use `if !FOO'. Tom
laser supplies
VORTEX SUPPLIES -SPECIALS OF THE DAY ON LASER TONER SUPPLIES AT DISCOUNT PRICES-- ORDER BY PHONE:1-888-288-9043 ORDER BY FAX: 1-888-977-1577 E-MAIL REMOVAL LINE: 1-888-248-4930 UNIVERSITY AND/OR SCHOOL PURCHASE ORDERS WELCOME. (NO CREDIT APPROVAL REQUIRED) ALL OTHER PURCHASE ORDER REQUESTS REQUIRE CREDIT APPROVAL. PAY BY CHECK (C.O.D), CREDIT CARD OR PURCHASE ORDER (NET 30 DAYS). IF YOUR ORDER IS BY CREDIT CARD PLEASE LEAVE YOUR CREDIT CARD # PLUS EXPIRATION DATE. IF YOUR ORDER IS BY PURCHASE ORDER LEAVE YOUR SHIPPING/BILLING ADDRESSES AND YOUR P.O. NUMBER NOTE: WE DO NOT CARRY 1) XEROX, BROTHER, PANASONIC, FUJITSU PRODUCTS 2) DESKJETJET/INK JET OR BUBBLE JET CARTRIDGES 3) ANY OFFBRANDS BESIDES THE ONES LISTED BELOW. OUR NEW , LASER PRINTER TONER CARTRIDGE, PRICES ARE AS FOLLOWS: (PLEASE ORDER BY PAGE NUMBER AND/OR ITEM NUMBER) FOR HEWLETT PACKARD: (ON PAGE 2) ITEM #1 LASERJET SERIES 4L,4P (74A)$44 ITEM #2 LASERJET SERIES 1100 (92A)-$44 ITEM #3 LASERJET SERIES 2 (95A)$39 ITEM #4 LASERJET SERIES 2P (75A)---$54 ITEM #5 LASERJET SERIES 5P,6P,5MP, 6MP (3903A)-- -$44 ITEM #6 LASERJET SERIES 5SI, 8000 (09A)$95 ITEM #7 LASERJET SERIES 2100, 2200 (96A)---$74 ITEM #8 LASERJET SERIES 8100 (82X)-$115 ITEM #9 LASERJET SERIES 5L/6L (3906A)--$39 ITEM #10 LASERJET SERIES 4V-$95 ITEM #11 LASERJET SERIES 4000 (27X)--$79 ITEM #12 LASERJET SERIES 3SI/4SI (91A)---$54 ITEM #13 LASERJET SERIES 4, 4M, 5,5M-$49 ITEM #13A LASERJET SERIES 5000 (29X)-$125 ITEM #13B LASERJET SERIES 1200---$59 ITEM #13C LASERJET SERIES 4100---$99 ITEM #18 LASERJET SERIES 3100--$39 ITEM #19 LASERJET SERIES 4500 BLACK--$79 ITEM #20 LASERJET SERIES 4500 COLORS $125 FOR HEWLETT PACKARD FAX (ON PAGE 2) ITEM #14 LASERFAX 500, 700 (FX1)--$49 ITEM #15 LASERFAX 5000,7000 (FX2)$64 ITEM #16 LASERFAX (FX3)--$59 ITEM #17 LASERFAX (FX4)--$54 FOR LEXMARK/IBM (ON PAGE 3) OPTRA 4019, 4029 HIGH YIELD---$89 OPTRA R, 4039, 4049 HIGH YIELD---$105 OPTRA E310.312 HIGH YIELD$79 OPTRA E---$59 OPTRA N--$115 OPTRA S--$165 OPTRA T--$195 OPTRA E310/312---$79 OPTAA E410/412---$89 FOR EPSON (ON PAGE 4) ACTION LASER 7000,7500,8000,9000--$105 ACTION LASER 1000,1500$105 FOR CANON PRINTERS (ON PAGE 5) PLEASE CALL FOR MODELS AND UPDATED PRICES FOR CANON PRINTER CARTRIDGES PANASONIC (0N PAGE 7) NEC SERIES 2 MODELS 90 AND 95--$105 APPLE (0N PAGE 8) LASER WRITER PRO 600 or 16/600--$49 LASER WRITER SELECT 300,320,360-$74 LASER WRITER 300 AND 320$54 LASER WRITER NT, 2NT$54 LASER WRITER 12/640-$79 FOR CANON FAX (ON PAGE 9) LASERCLASS 4000 (FX3)---$59 LASERCLASS 5000,6000,7000 (FX2)-$54 LASERFAX 5000,7000 (FX2)$54 LASERFAX 8500,9000 (FX4)$54 FOR CANON COPIERS (PAGE 10) PC 3, 6RE, 7 AND 11 (A30)-$69 PC 300,320,700,720,760,900,910,920(E-40)--$89 90 DAY UNLIMITED WARRANTY INCLUDED ON ALL PRODUCTS. ALL TRADEMARKS AND BRAND NAMES LISTED ABOVE ARE PROPERTY OF THE RESPECTIVE HOLDERS AND USED FOR DESCRIPTIVE PURPOSES ONLY.
Re: what is this shell call trying to solve?
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes: Akim> Now if that causes real problems, not just esthetics, then of Akim> course it ought to be fixed. Sometimes these esthetic considerations are important -- to me anyway. Also, in this case there is a small performance penalty for the existing code. One problem I see in automake is that the features we support add performance penalties to the resulting Makefile. This in turn can be used to argue against using automake. So I prefer to try to reduce these penalties when possible. As an example, I'm still interested in changing depend2.am so that if depmode=gcc3, then we avoid using depcomp. This will make depend2 a bit harder to maintain. But it will add a nice optimization for developers using free software. Tom
Re: AM_CONDITIONAL and config.status
On Sat, Feb 02, 2002 at 11:07:15AM -0700, Tom Tromey wrote: > > "Roger" == Roger Leigh <[EMAIL PROTECTED]> writes: > > Roger> in Makefile.in, is it safe to use this format in my own .in files (e.g. > Roger> po/POTFILES.in), or will the format used for the conditionals in .in > Roger> files change at a future date? What I need to do is have lines > Roger> conditionally included, as some are conditionally distributed. > > Conditionals don't work they way you seem to think they do. > The @FOO_TRUE@ is rewritten to either `' (empty string) or `#' (make > comment) by configure. No line is omitted from the generated Makefile. > > My recommendation is not to rely on the implementation of > conditionals. It isn't something we have ever documented. We might > actually change it at some point; for instance we might be able to get > better performance from config.status if we change how conditionals > are implemented. OK. Back to the drawing board ;-) I did actually get this working: @GIMP_SOURCE_FALSE@# CUPS sources @GIMP_SOURCE_FALSE@src/cups/genppd.c @GIMP_SOURCE_FALSE@# Foomatic-related sources @GIMP_SOURCE_FALSE@src/foomatic/printer_options.c ==> # CUPS sources src/cups/genppd.c # Foomatic-related sources src/foomatic/printer_options.c When GIMP_SOURCE is true, the lines are nicely commented out with '#'. I won't use this though ;-) > Roger> if COND > Roger> FOO > Roger> BAR > Roger> BAZ > Roger> else > Roger> BAD > Roger> endif > > I read this example but I don't understand how it differs from what we > already do. Right now you can enclose all kinds of stuff in a single > conditional. What you can't do is have a conditional that starts or > ends in the middle of a rule or macro definition. OK. I though that in the past I could only have one line between if-endif or if-else or else-endif. That was quite some time ago though. automake.info only gives examples which use a single line. > Roger> Being able to use 'ifndef' would also be another nice addition, > Roger> or has this already been done (I possibly remember this being > Roger> mentioned). > > You can use `if !FOO'. Great. Many thanks, Roger -- Roger Leigh ** Registration Number: 151826, http://counter.li.org ** Need Epson Stylus Utilities? http://gimp-print.sourceforge.net/ GPG Public Key: 0x25BFB848 available on public keyservers
Re: AM_CONDITIONAL and config.status
> "Roger" == Roger Leigh <[EMAIL PROTECTED]> writes: Roger> OK. I though that in the past I could only have one line between Roger> if-endif or if-else or else-endif. It has always worked to put a lot of stuff inside the condition. Tom
