Re: distcheck problem.
OKAY! I finally got it working. It didn't used to cause problems the way I was doing things before. But anyway it's working now. Thanks for your help. Alexandre Duret-Lutz wrote: [...] Davy> These files are listed in the DIST_COMMON (at least I'm pretty sure Davy> DIST_COMMON is where these files are coming from in the cp commands) Davy> so I'm not explicitly listing them myself anywhere to be distributed. Davy> I've tried several versions between and including 1.6.3 to 1.7.5 I think you should definitely revise the way you use EXTRA_DIST in your Makefile.am. Automake is designed to distribute files using an opt-in strategy. Most of the times, Automake can figure automatically what files to distribute. Sometimes, there are a few files that Automake does not know about but that you want to distribute: you should list each of these files in EXTRA_DIST. What your Makefile.am tries to implement is an opt-out strategy: all directories are listed in EXTRA_DIST, and with a dist-hook you clean the mess by removing most of the unwanted cruft. This will only get you into trouble. EXTRA_DISTing directories should be reserved to directories with generated/dynamic contents. Perhaps they can be useful in other situations too, but at least EXTRA_DISTing a directory which appears in SUBDIRS looks really awkward (your config/ directory is not in SUBDIRS but you have a few other directories in this situation). The (more specific) error you report is related to the fact that Automake has already decided to distribute the files from config/ that it needs (those you mention), and yet you are EXTRA_DISTing this config/ directory. Some implementation details prevent a file from being distributed both individually and as a directory member. For more on this config/ issue, see PR/390 in the Automake Gnats database. A related topic to EXTRA_DISTing subdirectories is the use of wildcards: there is a entry about this in the Automake FAQ (in recent manuals).
failure notice
Hi. This is the qmail-send program at mail.ccbtc.com. I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out. <[EMAIL PROTECTED]>: Sorry, no mailbox here by that name. vpopmail (#5.1.1) --- Below this line is a copy of the message. Return-Path: <[EMAIL PROTECTED]> Received: (qmail 19681 invoked from network); 19 Jun 2003 03:21:18 - Received: from unknown (HELO b2b) (218.17.92.96) by 0 with SMTP; 19 Jun 2003 03:21:18 - From: "automake" <[EMAIL PROTECTED]> Subject: =?GB2312?B?z8jJ+srVLM/yxPrNxrz2z/rK29OvwPu5pL7f?=11:18:31: To: [EMAIL PROTECTED] Content-Type: text/plain;charset="GB2312" Sender: automake <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] Date: Thu, 19 Jun 2003 11:18:32 +0800 X-Priority: 1 X-Mailer: Microsoft Outlook Express 5.50.4133.2400 ,ÄúºÃ! ÏòÄúÍƼöÎÒÃǵIJúÆ·¡¶ÉÌÖÇÈí¼þ¡·,ËýÊÇÒ»¿îÄÜ°ïÖú¹ó˾µÄÊг¡²¿´ó·ùÌáÉýÒµ¼¨µÄ»¥ÁªÍøÒµÎñ¹¤¾ß¡£ Ëý¾ßÓдÓ2000¶à¼Ò½»Ò×Õ¾µã»ñÈ¡ÐÅÏ¢£¬²¢¿ÉÒÔÔÚ1500¶à¼ÒÉÌÎñƽ̨ÉϽøÐÐÐÅÏ¢·¢²¼¡£ Ëý¿ÉÒÔ´ÓÍøÉÏËÑË÷ÄúµÄÖ±½Ó¿Í»§ÈºµÄÓʼþµØÖ·£¬²¢¿ÉÒÔ½«ÄúµÄÐÅÏ¢Ò»´ÎÐÔ·¢Ë͸ø¶Ô·½¡£ ËýÓµÓÐÇ¿´óÐÅÏ¢¹ÜÀí¹¦ÄÜ£¬²¢Í¨¹ýÍøÂçȺ·¢¹¦Äܽ«ÐÅÏ¢Ö±½ÓË͵½ÈκÎһ̨ÉÏÍøµÄÖ÷»ú¡£ ÏÖÔÚÌØ¿ªÍ¨£²£´Ð¡Ê±µÄÍøÉϲÙ×÷×ÉѯÁªÏµ QQ£º39398668¡¢5189773¡¢2697361¡¢14378901 [EMAIL PROTECTED]@hotmail.com [EMAIL PROTECTED] Èç¹ûÄúÏë½øÒ»²½µÄÁ˽âÉÌÖÇ£¬ÇëÄúÒÔ¡°Ô¸ÒâÁ˽âһϡ±ÎªÖ÷Ìâ»Ø¸´±¾Óʼþ Èç¹ûÄú²»ÏëÔÙÊÕµ½ÀàËÆÓʼþ£¬ÇëÄúÒÔ¡°remove¡±ÎªÖ÷Ìâ»Ø¸´±¾Óʼþ
Re: distcheck problem.
Hi Davy, >>> "Davy" == Davy Durham <[EMAIL PROTECTED]> writes: [...] Davy> These files are listed in the DIST_COMMON (at least I'm pretty sure Davy> DIST_COMMON is where these files are coming from in the cp commands) Davy> so I'm not explicitly listing them myself anywhere to be distributed. Davy> I've tried several versions between and including 1.6.3 to 1.7.5 I think you should definitely revise the way you use EXTRA_DIST in your Makefile.am. Automake is designed to distribute files using an opt-in strategy. Most of the times, Automake can figure automatically what files to distribute. Sometimes, there are a few files that Automake does not know about but that you want to distribute: you should list each of these files in EXTRA_DIST. What your Makefile.am tries to implement is an opt-out strategy: all directories are listed in EXTRA_DIST, and with a dist-hook you clean the mess by removing most of the unwanted cruft. This will only get you into trouble. EXTRA_DISTing directories should be reserved to directories with generated/dynamic contents. Perhaps they can be useful in other situations too, but at least EXTRA_DISTing a directory which appears in SUBDIRS looks really awkward (your config/ directory is not in SUBDIRS but you have a few other directories in this situation). The (more specific) error you report is related to the fact that Automake has already decided to distribute the files from config/ that it needs (those you mention), and yet you are EXTRA_DISTing this config/ directory. Some implementation details prevent a file from being distributed both individually and as a directory member. For more on this config/ issue, see PR/390 in the Automake Gnats database. A related topic to EXTRA_DISTing subdirectories is the use of wildcards: there is a entry about this in the Automake FAQ (in recent manuals). -- Alexandre Duret-Lutz
Re: spam
>>> "Bob" == Bob Rossi <[EMAIL PROTECTED]> writes: Bob> Hi, Bob> Is there some sort of Email filter you guys could use to Bob> keep spam at a minimum. It seems like the automake mailing list Bob> recieves a lot of spam ( in comparison to other mailing lists ). spam is filtered globally on all gnu.org lists since last summer[*]. There is nothing we can do here about this. You should discuss this matter on the [EMAIL PROTECTED] mailing list. [*] You can get the feeling here: http://sources.redhat.com/ml/bug-automake/2002/ -- Alexandre Duret-Lutz
Re: Problem with libtool
> I did just see a similar problem, but it was related with > re'configure'ingof the project sources with a different --prefix. > It seems that the > libtool .la file is not updated with the new prefix, I had to `make > clean`before it got it right. Perhaps there's a similar thing about > your stuff > here that the linker script (.la) has an old prefix from an earlier > build? > have fun, > -- guido Yes, 'make clean' solved the problem :) thanks /Marcus
Re: Problems getting dependencies compiled before executable....
>>> "Assar" == Assar Westerlund <[EMAIL PROTECTED]> writes: [...] Assar> bar/libbar.la: Assar> cd bar && $(MAKE) libbar.la Unless you declare this rule as PHONY (or list all the dependencies of bar/libbar.la and the dependencies thereof) this introduces a bug in the case the library already exists. Your program will be linked to the old library, and then the library will be rebuilt when make enter the subdirectory as part of the SUBDIRS recursion. -- Alexandre Duret-Lutz
Re: Problem with libtool
Marcus Bjurman schrieb: Hi, My project (http://www.nongnu.org/gcmd/) consists of two parts. One shared library and one ordinary executable linked agains the library. The library gets built alright but when building the executable libtool doesn't respect the $prefix that was choosen at configure-time. What I mean is that the rpath that libtool uses at link-time always gets set to /usr/local/lib regardless of the $prefix. This obviously causes a problem after the install since the executable is linked against a library in /usr/local/lib that doesn't exist. I checked the libtool script av saw that the variable used for rpath is libdir. Checking further I saw that all makefiles have libdir setup correctly to $(prefix)/lib. So my question basicly is: where does libtool get the libdir variable from? And then what is the correct way of getting the correct value there? BTW: I have checked other packages such as xmms that has the same basic layout with a library and an executable. They all work so its not a problem with the installation, its rather a problem with me not being able to figure out why they work and not my project ;) Please CC replies to me /Marcus I did just see a similar problem, but it was related with re'configure'ing of the project sources with a different --prefix. It seems that the libtool .la file is not updated with the new prefix, I had to `make clean` before it got it right. Perhaps there's a similar thing about your stuff here that the linker script (.la) has an old prefix from an earlier build? have fun, -- guido http://google.de/search?q=guidod GCS/E/S/P C++/$ ULHS L++w- N++@ d(+-) s+a- r+@>+++ y++ 5++X- (geekcode)
Re: Quick Upgrade Question
Actually, I'm only upgrading because I'm trying to install a package that requires the new autoconf/make so I'm not sure that the autoreconf and autoupdate are necessary, but I will look into those commands if I run into a problem. Thanks... Btw, sorry about the previous mail in HTML format, shouldn't happen again... Joel - Original Message - From: "Assar Westerlund" <[EMAIL PROTECTED]> To: "Joel Apter" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Tuesday, June 17, 2003 6:05 PM Subject: Re: Quick Upgrade Question > "Joel Apter" <[EMAIL PROTECTED]> writes: > > matter). Would a simple configure, make, make install be all that is > > necessary for both automake and autoconf (autoconf before automake > > since it appears that autoconf 2.54+ is required to install automake > > 1.7.5). Thank you for your time. > > Yes. And then you should be able to just run 'autoreconf -f -i' in > your package. You might also want to look at 'autoupdate' in the > autoconf manual. >
spam
Hi, Is there some sort of Email filter you guys could use to keep spam at a minimum. It seems like the automake mailing list recieves a lot of spam ( in comparison to other mailing lists ). Bob Rossi
Re: readme-alpha option and .90 pretests
Perhaps you should tell the people behind: The "gnit-picker gang", like I said, was a few friends, not an official group of any kind. I was one of them. http://www.amath.washington.edu/~lf/tutorials/autoconf/gnits/gnits.html Ah. It's been enough years that I'd forgotten that François (Pinard) had made up a skeleton gnits document, augmenting and with the same layout as the GNU coding standards. It was never supposed to be published. I don't see any email addresses at http://www.amath.washington.edu/~lf, so I can't write to him/her asking to remove it. I don't know who lf is, none of the gnits'ers have those initials. In any case, I'd guess it's been copied to a zillion places by now. All I can say is, again, the Gnits "standards" aren't real. Automake should just follow the GNU coding standards. If you don't believe me, you can write to [EMAIL PROTECTED] (a mailing list and domain that I maintain/own, by the way :). Note that even if you accept that document (which is fine, for what it is), it says GNU standards take precedence by a mile. Thanks, k
Problem with libtool
Hi, My project (http://www.nongnu.org/gcmd/) consists of two parts. One shared library and one ordinary executable linked agains the library. The library gets built alright but when building the executable libtool doesn't respect the $prefix that was choosen at configure-time. What I mean is that the rpath that libtool uses at link-time always gets set to /usr/local/lib regardless of the $prefix. This obviously causes a problem after the install since the executable is linked against a library in /usr/local/lib that doesn't exist. I checked the libtool script av saw that the variable used for rpath is libdir. Checking further I saw that all makefiles have libdir setup correctly to $(prefix)/lib. So my question basicly is: where does libtool get the libdir variable from? And then what is the correct way of getting the correct value there? BTW: I have checked other packages such as xmms that has the same basic layout with a library and an executable. They all work so its not a problem with the installation, its rather a problem with me not being able to figure out why they work and not my project ;) Please CC replies to me /Marcus
Please confirm your request to join KinkyGoldCoast
Hello [EMAIL PROTECTED], We have received your request to join the KinkyGoldCoast group hosted by Yahoo! Groups, a free, easy-to-use community service. This request will expire in 21 days. TO BECOME A MEMBER OF THE GROUP: 1) Go to the Yahoo! Groups site by clicking on this link: http://groups.yahoo.com/i?i=zPMDcgRWbMIR2-_pJgkgnVCoKMM&e=automake%40gnu%2Eorg (If clicking doesn't work, "Cut" and "Paste" the line above into your Web browser's address bar.) -OR- 2) REPLY to this email by clicking "Reply" and then "Send" in your email program If you did not request, or do not want, a membership in the KinkyGoldCoast group, please accept our apologies and ignore this message. Regards, Yahoo! Groups Customer Care Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Re: readme-alpha option and .90 pretests
On Tue, 17 Jun 2003, Karl Berry wrote: > comes from the Gnits standards. > There is no such thing as "Gnits standards". I was/am a founding member > of "gnits" (which was just a few friends talking informally), and I can > state this authoritatively :). Perhaps you should tell the people behind: http://www.amath.washington.edu/~lf/tutorials/autoconf/gnits/gnits.html ? rlc
