Do not install a binary
Hello, I have a binary that I use as a build tool only to build the rest of the package and dont want to install it. Any ideas about how to write up a Makefile.am for this? Please reply to me directly as I am not on this list. Thanks, Laszlo
Re: Do not install a binary
I have a binary that I use as a build tool only to build the rest of the package and dont want to install it. Any ideas about how to write up a Makefile.am for this? Laszlo, There is a noinst label for this. For instance, in your Makefile.am : noinst_PROGRAMS = yourbintool which works like the bin_PROGRAMS construct. Use yourbintool_SOURCES and so on then. -- Stéphane Genaud IECS, Université Robert Schuman 61 av. de la Forêt Noire, 67085 Strasbourg Bureau 107 tel : 0390414298
Re: Do not install a binary
Stephane Genaud wrote: I have a binary that I use as a build tool only to build the rest of the package and dont want to install it. Any ideas about how to write up a Makefile.am for this? Laszlo, There is a noinst label for this. For instance, in your Makefile.am : noinst_PROGRAMS = yourbintool which works like the bin_PROGRAMS construct. Use yourbintool_SOURCES and so on then. Thanks, it worked. Laszlo
aclocal -I
It would be great if one could add -I options to aclocal by just placing macros in configure.ac, like: AC_CONFIG_MACRO_DIR(conf/m4macros) That way I could run aclocal without having to remember the dirs or wrap the invocation in a script (aclocal scans configure.ac anyways). Would this be easily feasible, and are more people than me interested in something like this? Lars J -- This is your life and it's ending one minute at a time.
Re: sub conditionals_true_when (@@) [PATCH]
On Wed, Jun 13, 2001 at 11:44:52AM +0300, Kalle Olavi Niemitalo wrote: This bug is also causing the @TRUE@ conditions reported by Richard Boulton in Bug with conditionals. [PATCH]. You're right, this does seem to be the main cause of the problem I reported. I tried fixing the problem (by passing by reference instead). Unfortunately, this doesn't solve the problem; rather, it reveals that variable_conditions_reduce() is very bug ridden indeed. There seem to be two further problems: i) variable_conditions_reduce() currently checks conditions for redundancy against only those conditions which it has already checked, rather than against all the conditions it hasn't yet discarded. Thus, for example: FOO, FOO BAR will not reduce (since first FOO is checked against the empty conditional and then FOO BAR is checked against FOO), but FOO BAR, FOO will reduce to FOO BAR (since FOO BAR is checked against the empty conditional and then FOO is checked against FOO BAR). ii) The check for tautology of a condition performed by variable_conditions_reduce() checks whether all conditions in @CONDS are true for every condition in @WHENS. What is wanted is a check whether each condition in @CONDS is true for any of the conditions in @WHENS. The check is also the wrong way round: it keeps a condition if it is tautologous, rather than discarding it. I've put together another test case for this problem, cond12.test, which calls variable_conditions_reduce() to check the exact results for a set of inputs. I've also put together a patch to fix the problem, which causes cond11.test and cond12.test to pass (and all other tests to pass), and removes a FIXME from the code. The patch involves a straightforward fix for the bug reported by Kalle Olavi Niemitalo and for problem (i) in this email. (ii) is fixed by redefining the behaviour of conditionals_true_when() such that it returns TRUE if all the @CONDS are true for a condition in @WHENS. The behaviour when WHENS is empty is also altered to be more logical (this is where the FIXME is fixed). This should not affect any other code since conditionals_true_when() is only called with an array of size != 1 in @WHENS by variable_conditions_reduce(). The test suite all passes for me, including the two new tests, after this patch is applied. This patch supercedes the patch I submitted earlier. Hoping for a reply this time. ;-) -- Richard Index: ChangeLog === RCS file: /cvs/automake/automake/ChangeLog,v retrieving revision 1.1419 diff -u -r1.1419 ChangeLog --- ChangeLog 2001/06/12 14:37:44 1.1419 +++ ChangeLog 2001/06/14 19:01:32 @@ -1,3 +1,21 @@ +2001-06-06 Richard Boulton [EMAIL PROTECTED] + + * (conditionals_true_when): Pass parameters by reference, avoiding + bug which put all parameters in @CONDS instead of @WHENS. Report + by Kalle Olavi Niemitalo. + Return true if for each entry A in @CONDS there is an entry B in @WHENS + such that A is true when B. Previously returned true if for each + A in @CONDS, A is true for all B in @WHENS. + Remove FIXME; now treats an empty @WHENS as an empty conditional. + * (variable_conditions_reduce): Check whether each condition is + implied by any of the other conditions (other those already + discarded), rather than checking only against those already + considered (and kept). Also, fix sense of check: was keeping + tautologous terms instead of discarding them. + * tests/Makefile.am (TESTS): Added cond11.test and cond12.test. + * tests/cond11.test: New file. + * tests/cond12.test: New file. + 2001-06-12 Tom Tromey [EMAIL PROTECTED] * automake.texi (ANSI): Minor clarification. Index: automake.in === RCS file: /cvs/automake/automake/automake.in,v retrieving revision 1.1137 diff -u -r1.1137 automake.in --- automake.in 2001/06/09 00:34:28 1.1137 +++ automake.in 2001/06/14 19:01:46 @@ -5315,25 +5315,34 @@ # $BOOLEAN -# conditionals_true_when (@CONDS, @WHENS) +# conditionals_true_when (\@CONDS, \@WHENS) # -# Same as above, but true if all the @CONDS are true when *ALL* -# the @WHENS are sufficient. +# Same as above, but true if all the @CONDS are true for at least one of the +# conditional strings in @WHENS. # -# If there are no @CONDS, then return true, of course. *BUT*, even if there -# are @CONDS but @WHENS is empty, return true. This is counter intuitive, -# and against all the rules of logic, but is needed by the current code. -# FIXME: Do something saner when the logic of conditionals is understood. -sub conditionals_true_when (@@) +# If there are no @CONDS, then return true. +# If there are no @WHENS, then behave as if @WHENS contained a single empty +# condition. +sub
Re: sub conditionals_true_when (@@) [PATCH]
Richard Boulton [EMAIL PROTECTED] writes:
On Wed, Jun 13, 2001 at 11:44:52AM +0300, Kalle Olavi Niemitalo wrote:
This bug is also causing the @TRUE@ conditions reported by
Richard Boulton in Bug with conditionals. [PATCH].
You're right, this does seem to be the main cause of the problem I
reported.
I tried fixing the problem (by passing by reference instead).
[snip]
# $BOOLEAN
-# conditionals_true_when (@CONDS, @WHENS)
+# conditionals_true_when (\@CONDS, \@WHENS)
#
[snip]
+sub conditionals_true_when ($$)
{
-my (@conds, @whens) = @_;
+my ($condsref, $whensref) = @_;
Isn't it cleaner to use
sub conditions_true_when(\@@)
{
my ($condsref, @whens) = @_;
You also get the benefit of type-checking.
- if ! conditionals_true_when ((@parent_conds), ($vcond));
+if ! conditionals_true_when ([@parent_conds], [$vcond]);
This would then be,
if ! conditionals_true_when(@parent_conds, $vcond)
- Hari
--
Raja R Harinath -- [EMAIL PROTECTED]
When all else fails, read the instructions. -- Cahn's Axiom
Our policy is, when in doubt, do the right thing. -- Roy L Ash
KEEP 100% OF THE REVENUE YOU GENERATE!
Dear Friend, AS SEEN ON NATIONAL TV : ''Making over half million dollars every 4 to 5 months from your home for an investment of only $25 US Dollars expense one time'' THANKS TO THE COMPUTER AGE AND THE INTERNET! = BE A MILLIONAIRE LIKE OTHERS WITHIN A YEAR!!! Before you say ''Bull'', please read the following. This is the letter you have been hearing about on the news lately. Due to the popularity of this letter on the Internet, a national weekly news program recently devoted an entire show to the investigation of this program described below, to see if it really can make people money. The show also investigated whether or not the program was legal. Their findings proved once and for all that there are ''absolutely NO laws prohibiting the participation in the program and if people can follow the simple instructions, they are bound to make some mega bucks with only $25 out of pocket cost''. DUE TO THE RECENT INCREASE OF POPULARITY RESPECT THIS PROGRAM HAS ATTAINED, IT IS CURRENTLY WORKING BETTER THAN EVER. This is what one had to say: ''Thanks to this profitable opportunity. I was approached many times before but each time I passed on it. I am so glad I finally joined just to see what one could expect in return for the minimal effort and money required. To my astonishment, I received total $ 610,470.00 in 21 weeks, with money still coming in''. Pam Hedland, Fort Lee, New Jersey. - Here is another testimonial: ''This program has been around for a long time but I never believed in it. But one day when I received this again in the mail I decided to gamble my $25 on it. I followed the simple instructions and voila' - 3 weeks later the money started to come in. First month I only made $240.00 but the next 2 months after that I made a total of $290,000.00. So far, in the past 8 months by re-entering the program, I have made over $710,000.00 and I am playing it again. The key to success in this program is to follow the simple steps and NOT change anything'' More testimonials later but first, PRINT THIS NOW FOR YOUR FUTURE REFERENCE $$$ If you would like to make at least $500,000 every 4 to 5 months easily and comfortably, please read the following...THEN READ IT AGAIN and AGAIN!!! $$$ FOLLOW THE SIMPLE INSTRUCTION BELOW AND YOUR FINANCIAL DREAMS WILL COME TRUE, GUARANTEED! INSTRUCTIONS: Order all 5 reports shown on the list below. For each report, send $5 CASH, THE NAME NUMBER OF THE REPORT YOU ARE ORDERING and YOUR E-MAIL ADDRESS to the person whose name appears ON THAT LIST next to the report. MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE TOP LEFT CORNER in case of any mail problems. When you place your order, make sure you order each of the 5 reports. You will need all 5 reports so that you can save them on your computer and resell them. YOUR TOTAL COST $5 X 5 = $25.00. You will receive, vie e-mail, each of the 5 reports from these 5 different individuals. Save them on your computer so they will be accessible for you to send to the 1,000's of people who will order them from you. Also make a floppy of these reports and keep it on your desk in case something happen to your computer. IMPORTANT __ DO NOT alter the names of the people who are listed next to each report, or their sequence on the list, in any way other than what is instructed below in step '' 1 through 6 '' or you will loose out on majority of your profits. Once you understand the way this works, you will also see how it does not work if you change it. Remember, this method has been tested, and if you alter, it will NOT work!!! People have tried to put their friends/relatives names on all five thinking they could get all the money. But it does not work this way. Believe us, we all have tried to be greedy and then nothing happened. So Do Not try to change anything other than what is instructed. Because if you do, it will not work for you. Remember, honesty reaps the reward!!! 1After you have ordered all 5 reports, take this advertisement and REMOVE the name address of the person in REPORT #5. This person has made it through the cycle and is no doubt counting their fortune. 2Move the name address in REPORT #4 down TO REPORT #5. 3Move the name address in REPORT #3 down TO REPORT #4. 4Move the name address in REPORT #2 down TO REPORT #3. 5Move the name address in REPORT #1 down TO REPORT #2 6Insert YOUR name address in the REPORT #1 Position. PLEASE MAKE SURE you copy every name address ACCURATELY! = Take this entire letter, with the modified list of names, and save it on your computer. DO NOT MAKE ANY
Re: sub conditionals_true_when (@@) [PATCH]
On Thu, Jun 14, 2001 at 03:17:38PM -0500, Raja R Harinath wrote:
Isn't it cleaner to use
sub conditions_true_when(\@@)
{
my ($condsref, @whens) = @_;
[snip]
- if ! conditionals_true_when ((@parent_conds), ($vcond));
+ if ! conditionals_true_when ([@parent_conds], [$vcond]);
This would then be,
if ! conditionals_true_when(@parent_conds, $vcond)
This bit may be neater, but in variable_conditions_reduce() we have a
scalar to pass as the first argument, rather than an array. \@ prevents us
from using an anonymous array, so we need a temporary variable, or to
restructure the code in variable_conditions_reduce() to use an array all
the time. I can't see a good way to do this restructuring, and therefore
think this balances out the other neatness by itself.
It also seems cleaner to me to treat both arguments the same, since they
both have the same type. But maybe that's just because I'm a C coder more
than a perl coder.
There's no good reason not to do:
if ! conditionals_true_when (\@parent_conds, [$vcond]);
though, now you mention it. ;-)
--
Richard
libtool is not removed in 1.4f, but is removed in 1.4-p4
In a Makefile which is created using automake-1.4f, libtool is not removed by distclean-am, in fact, it doesn't seem to be removed at all. In automake-1.4-p4, libtool is removed by distclean-am. These are the libtool related macros which I use: AC_LIBTOOL_DLOPEN AC_DISABLE_SHARED AC_PROG_LIBTOOL AC_SUBST(LIBTOOL_DEPS) -- Kevin Dalley [EMAIL PROTECTED]
Re: AM_CFLAGS and sub/foo.c
Steve == Steve M Robbins [EMAIL PROTECTED] writes: Steve Given the following Makefile.am Steve bin_PROGRAMS = foo Steve foo_SOURCES = foo.c sub/foo2.c Steve it turns out that foo.c is compiled using $(COMPILE), and hence Steve includes AM_CFLAGS. However, foo2.c is compiled *without* Steve AM_CFLAGS. Thanks for noticing this! What I intended is that by default everything is compiled with AM_CFLAGS. But if there are per-executable CFLAGS in effect, then AM_CFLAGS is omitted. So I agree you've found a bug. Your message, plus my recent adventures into automake.texi, make me wonder if this is the best approach. It would certainly be easier to document if AM_CFLAGS was simply always used. Now is the time to decide this sort of thing -- before 1.5 goes out. Any comments? Reasons to prefer one over the other? As I recall I planned it this way on the theory that adding AM_CFLAGS to the per-exe CFLAGS is easy for the user, but removing it would be hard. Tom
Re: interpolating automake variables?
Rusty == Rusty Ballinger [EMAIL PROTECTED] writes:
Rusty Is there a simpler way to do this? It seems like you'd wind up
Rusty doing a lot of work which automake already does.
Another method is to use a macro (available at the macro archive) to
expand $prefix or whatever at configure time into a separate variable
which you AC_SUBST, and then just go ahead and use AC_OUTPUT.
In some ways this isn't as friendly.
Automake itself takes the cheapo hack route:
my $prefix = @prefix@;
my $perllibdir = $ENV{'perllibdir'} || @datadir@/@PACKAGE@;
This is ugly, but it has worked for years.
Tom
Re: problems with mdate-sh and version.texi without AC_CONFIG_AUX_DIR in 1.4f
Kevin == Kevin Dalley [EMAIL PROTECTED] writes: Kevin If AC_CONFIG_AUX_DIR is not used, and version.texi is in a doc Kevin directory, than automake -a installs mdate-sh in top_srcdir, Kevin but the Makefile.in in the doc directory tries to use mdate-sh Kevin in srcdir, which mdate-sh does not exist. I wrote a test for this, but according to the test the right thing already happens. I'm checking in the test. It is `mdate4.test'. If you can tell me how to modify it to reproduce the bug, I'd be happy to fix the problem. But as it stands now I can't see it. Tom
Patches in Gnats?
We're starting to get patches which can't be checked in until post-1.5. I'm not even really interested in reviewing them until then. I was thinking I could create a new `patch' category in the automake Gnats and ask people to put such patches there as attachments. What do people think of this? Maybe this would help me with my problem of accidentally dropping patches too... Tom
Re: AM_CFLAGS and sub/foo.c
Steve == Steve M Robbins [EMAIL PROTECTED] writes: Steve The upshot is that foo.c is compiled using AM_CFLAGS but NOT Steve foo_CFLAGS, while foo2.c is compiled NOT using AM_CFLAGS but using Steve foo_CFLAGS. I'm checking in a fix for this. Tom
Re: config.sub/config.guess license exception, but not for 'missing'
Tom Tromey wrote: Akim == Akim Demaille [EMAIL PROTECTED] writes: Nathan == Nathan Neulinger Neulinger writes: Nathan Would y'all consider extending the license exception to Nathan include the 'missing' script as well? (I'm referring to the Nathan exception that allows distributing autoconf support files with Nathan apps that are not gpld. I'm not sure if there are other Nathan support files that are gpl'd, but the same request would apply Nathan there. Akim Hi, this is a question for Automake, not Autoconf. Do we really need this exception? I think including `missing' or whatever else in a non-GPL distribution is `mere aggregation' and already ok by the GPL. In any case I don't think there is a problem here. The clear intent for both autoconf and automake is that while the tools themselves are GPL, they can be used in any project. If I have to add exceptions to the support files, I will. But I don't think that is required. Tom I dunno, is it really mere aggregation if that 'missing' script is required as part of the build process for a non-gpl app? To me, the fact that that exception is spelled out for config.guess/config.sub and NOT for missing, is more important. If there were a general exception clearly spelled out in the license for both autoconf and automake such as The output of autoconf/automake, and any of the tools distributed with autoconf/automake that are necesarily to utilize that output, may be distributed under a license other than the GPL. -- Nathan Nathan Neulinger EMail: [EMAIL PROTECTED] University of Missouri - Rolla Phone: (573) 341-4841 CIS - Systems ProgrammingFax: (573) 341-4216
Re: aclocal -I
Lars == Lars J Aas [EMAIL PROTECTED] writes: Lars It would be great if one could add -I options to aclocal by just placing Lars macros in configure.ac, like: Lars AC_CONFIG_MACRO_DIR(conf/m4macros) That might be nice. I forget though what Akim has in mind for this for autoconf. The long term goal is to get rid of aclocal. Lars That way I could run aclocal without having to remember the dirs Lars or wrap the invocation in a script (aclocal scans configure.ac Lars anyways). You can use ACLOCAL_AMFLAGS (bad name, I know) in Makefile.am. Tom
Re: libtool is not removed in 1.4f, but is removed in 1.4-p4
Kevin == Kevin Dalley [EMAIL PROTECTED] writes: Kevin In a Makefile which is created using automake-1.4f, libtool is not Kevin removed by distclean-am, in fact, it doesn't seem to be removed at Kevin all. In automake-1.4-p4, libtool is removed by distclean-am. These Kevin are the libtool related macros which I use: Kevin AC_LIBTOOL_DLOPEN Kevin AC_DISABLE_SHARED Kevin AC_PROG_LIBTOOL Kevin AC_SUBST(LIBTOOL_DEPS) Can you tell me more about this bug? I don't see it. Run the appended test. Then look at the resulting Makefile.in. It shows that distclean depends on distclean-am, which depends on distclean-libtool, which does `rm -f libtool'. How can I modify this test to see the bug? Tom #! /bin/sh # Make sure libtool is removed. # Report from Kevin Dalley . $srcdir/defs || exit 1 cat configure.in 'END' AC_LIBTOOL_DLOPEN AC_DISABLE_SHARED AC_PROG_LIBTOOL AC_SUBST(LIBTOOL_DEPS) END cat Makefile.am 'END' lib_LTLIBRARIES = libfoo.la libfoo_la_SOURCES = foo.c END : ltmain.sh : config.guess : config.sub $ACLOCAL || exit 1 $AUTOMAKE || exit 1
Re: AM_CFLAGS and sub/foo.c
On Thu, Jun 14, 2001 at 06:51:09PM -0600, Tom Tromey wrote: Steve == Steve M Robbins [EMAIL PROTECTED] writes: Steve Given the following Makefile.am Stevebin_PROGRAMS = foo Stevefoo_SOURCES = foo.c sub/foo2.c Steve it turns out that foo.c is compiled using $(COMPILE), and hence Steve includes AM_CFLAGS. However, foo2.c is compiled *without* Steve AM_CFLAGS. Thanks for noticing this! What I intended is that by default everything is compiled with AM_CFLAGS. But if there are per-executable CFLAGS in effect, then AM_CFLAGS is omitted. So I agree you've found a bug. Your message, plus my recent adventures into automake.texi, make me wonder if this is the best approach. It would certainly be easier to document if AM_CFLAGS was simply always used. Now is the time to decide this sort of thing -- before 1.5 goes out. Any comments? Reasons to prefer one over the other? As I recall I planned it this way on the theory that adding AM_CFLAGS to the per-exe CFLAGS is easy for the user, but removing it would be hard. So what you are saying is that AM_CFLAGS and foo_CFLAGS will behave like LDADD and foo_LDADD (i.e. setting the foo_ version overrides the other)? I've always found this a bit of a nuisance with LDADD, to be honest. I normally want the program-specific flags _in addition_ to the generic flags. So I *always* have $(LDADD) in $foo_LDADD. I see that you've already checked in a fix: thanks! -Steve -- by Rocket to the Moon, by Airplane to the Rocket, by Taxi to the Airport, by Frontdoor to the Taxi, by throwing back the blanket and laying down the legs ... - They Might Be Giants
Re: CPP determined incorrectly
Pavel == Pavel Roskin [EMAIL PROTECTED] writes: How about merging AC_PROG_CPP and AC_PROG_CC together? What's the point of keeping the two of them? Pavel My concern is compatibility. There is no real reason to test Pavel for one but not the other, but if we go ahead and merge those Pavel macros a few dirty hacks may stop working. Dirty hacks must not exist :( The one you referred to will vanish as soon as Automake use traces. And we can leave some tricks to help people address their issues. And we _have_ to provide the interface they need to address their issues. But the current problem is that there is a huge dependency between CC and CPP, between CXX and CXXCPP etc. It's becoming a pure nightmare to synchronize all these people via AC_REQUIRE and so on. Pavel If you feel that you can handle it feel free to merge. It Pavel should be done earlier or later anyways. So you share my opinion?
Re: CPP determined incorrectly
Ralf == Ralf Corsepius [EMAIL PROTECTED] writes: Ralf This thought however raises another question: Why does Ralf AC_PROG_CPP exist at all? Ralf I would assume: * Some autoconf-users wanted to use CPP without Ralf CC (I have even seen cases were a host's native cpp have been Ralf applied to preprocess *.S to be processed with cross-assemblers Ralf :) ). MHO is just that at some time there was no reason to have them in a single macro. Today, Autoconf supports more languages, tests CPP and CC much more carefully etc. It's becoming a problem in itself. If you look at the archive, you'll see that we struggled a lot on these two guys. Yet it's not over. The former model, where is was `free' to have two macros, no longer applies. But again, this thinking is just based on my believing this is the way AC_PROG_CPP was born. ChangeLog is of no use, AFAICS. (That's the *first* ChangeLog entry :) Fri Apr 24 10:08:21 1992 David J. MacKenzie ([EMAIL PROTECTED]) * acspecific.m4 (AC_PROG_CPP): New macro. Then Fri May 15 00:57:01 1992 David J. MacKenzie ([EMAIL PROTECTED]) * acspecific.m4 (AC_PROG_CPP): Don't evaluate $CC until called. Try $CC -E before /lib/cpp. Then Mon Jun 15 21:27:49 1992 David J. MacKenzie ([EMAIL PROTECTED]) * acgeneral.m4 (AC_REQUIRE, AC_PROVIDE): New macros. (AC_HEADER_EGREP, AC_PROGRAM_EGREP, AC_TEST_CPP): Use them. * acspecific.m4 (AC_PROG_GCC, AC_GCC_TRADITIONAL, AC_PROG_CPP, AC_PROG_FLEX, AC_INLINE): Ditto. Ralf * History (Probably stemming from dependency-tracking) You envisioned it too :) Ralf Anyway, I am inclined to think we actually might be facing two Ralf issuses simulaneously: Ralf * CPP to be used by CC. Here, I do not understand why CPP is Ralf needed and available to users as a separate autoconf check at Ralf all. Unless I am missing something, IMHO, an implicit check Ralf inside of AC_PROG_CC etc. probably would be sufficient to Ralf provide an CCCPP or similar. AFAIU, this is what Akim and you Ralf have in mind. Yep! Ralf * CPP to be used as general tool. This is no way different from Ralf checking for and using any other arbitrary tool in Ralf autoconfizcated configurations. However, presence of Ralf AC_PROG_CPP in autoconf's set of specialized tool-checking Ralf macros causes users to apply it as such (i.e. I want CPP, Ralf AC_PROG_CPP exists, now I'll use it :). IMO, this is a Ralf different usage than what I think you have in mind. I think _this_ is a bad problem. It's not clear how to be backward compatible, but for instance, I'd like to merge AC_PROG_CPP into AC_PROG_CC, and then define AC_CHECK_CPP as a mere PATH walk to find cpp. All the heavy tests on CPP performed by AC_PROG_CPP are there *only* to have AC_CHECK_HEADERS and so on work properly.
depcomp problem [Fwd: Trying to compile latest CVS on old SCO unixware 2]
Sounds like this could be fixed in depcomp? Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] CollabNet ( http://collab.net ) -- Very funny Scotty, now beam down my clothes! Hi, I'm Trying to update an old SCO unixware 2 box...Currently I have CVS 1.10.8 there. (Yeah, shame on me) The cc's -o option refuses to overwrite existing .o files...: scameron@unixdev 208 $ make UX:make: WARNING: No suffix list. make all-recursive UX:make: WARNING: No suffix list. Making all in lib source='argmatch.c' object='argmatch.o' libtool=no \ depfile='.deps/argmatch.Po' tmpdepfile='.deps/argmatch.TPo' \ depmode=none /bin/sh ../depcomp \ cc -DHAVE_CONFIG_H -I. -I. -I.. -I../src -I../src -g -c -o argmatch.o `test -f argmatch.c || echo './'`argmatch.c UX:cc: ERROR: -o would overwrite argmatch.o *** Error code 1 (bu21) UX:make: ERROR: fatal error. *** Error code 1 (bu21) UX:make: ERROR: fatal error. *** Error code 1 (bu21) UX:make: ERROR: fatal error. I could edit the Makefile, but I know that's not the best way... (Maybe the best way is for me to install gcc, etc...) Any other thoughts? -- steve __ Do You Yahoo!? Spot the hottest trends in music, movies, and more. http://buzz.yahoo.com/ ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: depcomp problem [Fwd: Trying to compile latest CVS on old SCO unixware 2]
Derek == Derek R Price [EMAIL PROTECTED] writes: Derek Sounds like this could be fixed in depcomp? Maybe... Stephen I'm Trying to update an old SCO unixware 2 box...Currently I Stephen have CVS 1.10.8 there. (Yeah, shame on me) Stephen The cc's -o option refuses to overwrite existing .o files...: Wow, this is lame! I can't imagine why a compiler would do this. Do SCO hackers never run `make' to rebuild a project? Stephen source='argmatch.c' object='argmatch.o' libtool=no \ Stephen depfile='.deps/argmatch.Po' tmpdepfile='.deps/argmatch.TPo' \ Stephen depmode=none /bin/sh ../depcomp \ Stephen cc -DHAVE_CONFIG_H -I. -I. -I.. -I../src -I../src -g -c -o Stephen argmatch.o `test -f argmatch.c || echo './'`argmatch.c Stephen UX:cc: ERROR: -o would overwrite argmatch.o I want to know if this happens because argmatch.o already exists, or if it is because the SCO `cc' doesn't like `-c' and `-o' together. I want to make sure we really know what is going on. Could you run a test or two to make sure this is what is happening? If it is we can add an `rm -f foo.o' to the build rule. I would like to avoid that if possible though. Tom
Re: CPP determined incorrectly
Hello, Akim! Pavel If you feel that you can handle it feel free to merge. It Pavel should be done earlier or later anyways. So you share my opinion? I share your opinion that AC_PROG_CPP and AC_PROG_CC should be merged eventually. Whether it should be done before Autoconf-2.51 is another question. I personally don't want to risk, but if you think that you can make Automake work with the big macro (maybe by releasing another Automake-1.4-pX) without spending months on it then I'll support merging the macros now. -- Regards, Pavel Roskin
