From: Jim C. <ji...@ms...> - 2013-03-07 21:16:50
|
I'm a first time user of this list so I hope I'm addressing it to the proper group. I am trying to use the mingw32-make command on Windows 7, but receive an error every time stating "*** multiple target patterns". I have no idea what this means and have spent many hours online trying to find a solution. My guess from everything I've read is that it has to do with the first line in my makefile: INC = -Ic:\GTK\include\gtk-2.0 MAIN = graphictest OBJS = graphictest.o CC=gcc CFLAGS = -Wall -g $(MAIN): $(MAIN) $(OBJS) $(INC) When I run the mingw32-make -v command it tells me the version is 3.8.2. The command does work with simpler makefiles that don't specify an Include path. Any help anyone can offer is very much appreciated. Thanks...Jim C. |
From: Eli Z. <el...@gn...> - 2013-03-07 21:41:33
|
> Date: Thu, 7 Mar 2013 16:16:42 -0500 > From: Jim Crews <ji...@ms...> > > I'm a first time user of this list so I hope I'm addressing it to the > proper group. Actually, mak...@gn... is a better place. > I am trying to use the mingw32-make command on Windows 7, but receive an > error every time stating "*** multiple target patterns". I have no idea > what this means and have spent many hours online trying to find a solution. > > My guess from everything I've read is that it has to do with the first line > in my makefile: > > INC = -Ic:\GTK\include\gtk-2.0 > > MAIN = graphictest > OBJS = graphictest.o > > CC=gcc > CFLAGS = -Wall -g > > $(MAIN): $(MAIN) $(OBJS) $(INC) This Makefile uses $(INC) in a way that doesn't make sense to me. The value of INC is a compiler switch, but then why do you use it as a prerequisite for $(MAIN) ? See, what happens here is that you are stomping on a fragile feature of Make on Windows, whereby it understands that a colon ':' in certain contexts does not signal a target or a list of dependencies or a target pattern. But when you precede "c:" with -I, you break the logic which figures out that c: is a drive spec. So you get a nonsensical error message from Make. But since your usage of $(INC) doesn't make sense anyway, I don't think there's any bug in Make revealed by this. Simply don't do that; if you remove -I from the value of INC, everything is dandy. |
From: Jim C. <ji...@ms...> - 2013-03-07 22:24:12
|
Thanks so much for your response. As you may have guessed I'm new to this, but am trying to set everything up so I can begin learning some C and C++. I changed the variable name to INCLUDES (in case it conflicted with something I didn't know about) and removed the -I. Same problem. I also tried the following formats for assigning the variable: INCLUDES = -I"c:\GTK\include\gtk-2.0" INCLUDES = -I'c:\GTK\include\gtk-2.0' INCLUDES = "c:\GTK\include\gtk-2.0" INCLUDES = c:\GTK\include\gtk-2.0 which resulted in the same error. If I change the path to exclude the c: then I get the "fatal error: gtk/gtk.h: No such file or directory" On Thu, Mar 7, 2013 at 4:41 PM, Eli Zaretskii <el...@gn...> wrote: > > Date: Thu, 7 Mar 2013 16:16:42 -0500 > > From: Jim Crews <ji...@ms...> > > > > I'm a first time user of this list so I hope I'm addressing it to the > > proper group. > > Actually, mak...@gn... is a better place. > > > I am trying to use the mingw32-make command on Windows 7, but receive an > > error every time stating "*** multiple target patterns". I have no idea > > what this means and have spent many hours online trying to find a > solution. > > > > My guess from everything I've read is that it has to do with the first > line > > in my makefile: > > > > INC = -Ic:\GTK\include\gtk-2.0 > > > > MAIN = graphictest > > OBJS = graphictest.o > > > > CC=gcc > > CFLAGS = -Wall -g > > > > $(MAIN): $(MAIN) $(OBJS) $(INC) > > This Makefile uses $(INC) in a way that doesn't make sense to me. The > value of INC is a compiler switch, but then why do you use it as a > prerequisite for $(MAIN) ? > > See, what happens here is that you are stomping on a fragile feature > of Make on Windows, whereby it understands that a colon ':' in certain > contexts does not signal a target or a list of dependencies or a > target pattern. But when you precede "c:" with -I, you break the > logic which figures out that c: is a drive spec. So you get a > nonsensical error message from Make. > > But since your usage of $(INC) doesn't make sense anyway, I don't > think there's any bug in Make revealed by this. Simply don't do that; > if you remove -I from the value of INC, everything is dandy. > > > ------------------------------------------------------------------------------ > Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester > Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the > endpoint security space. For insight on selecting the right partner to > tackle endpoint security challenges, access the full report. > http://p.sf.net/sfu/symantec-dev2dev > _______________________________________________ > MinGW-users mailing list > Min...@li... > > This list observes the Etiquette found at > http://www.mingw.org/Mailing_Lists. > We ask that you be polite and do the same. Disregard for the list > etiquette may cause your account to be moderated. > > _______________________________________________ > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > Also: mailto:min...@li...?subject=unsubscribe > |
From: Eli Z. <el...@gn...> - 2013-03-07 22:48:26
|
> Date: Thu, 7 Mar 2013 17:16:58 -0500 > From: Jim Crews <ji...@ms...> > > I changed the variable name to INCLUDES (in case it conflicted with > something I didn't know about) and removed the -I. Same problem. That does work for me. Maybe you should show a more or less complete Makefile, there could be other, unrelated, problems there. > I also tried the following formats for assigning the variable: > > INCLUDES = -I"c:\GTK\include\gtk-2.0" > INCLUDES = -I'c:\GTK\include\gtk-2.0' > INCLUDES = "c:\GTK\include\gtk-2.0" > INCLUDES = c:\GTK\include\gtk-2.0 The last one should have worked (it did for me), unless there are other factors at work here. All the rest are duds, as Make doesn't understand quoted file names in dependencies. |
From: Earnie B. <ea...@us...> - 2013-03-08 13:52:00
|
On Thu, Mar 7, 2013 at 5:16 PM, Jim Crews <ji...@ms...> wrote: PLEASE DO NOT TOP POST. See http://mingw.org/lists.shtml for Etiquette. > Thanks so much for your response. As you may have guessed I'm new to this, > but am trying to set everything up so I can begin learning some C and C++. > > I changed the variable name to INCLUDES (in case it conflicted with That doesn't matter. > something I didn't know about) and removed the -I. Same problem. I also > tried the following formats for assigning the variable: > > INCLUDES = -I"c:\GTK\include\gtk-2.0" > INCLUDES = -I'c:\GTK\include\gtk-2.0' > INCLUDES = "c:\GTK\include\gtk-2.0" > INCLUDES = c:\GTK\include\gtk-2.0 > Ok, but ... > which resulted in the same error. If I change the path to exclude the c: > then I get the "fatal error: gtk/gtk.h: No such file or directory" > > > On Thu, Mar 7, 2013 at 4:41 PM, Eli Zaretskii <el...@gn...> wrote: >> >> > Date: Thu, 7 Mar 2013 16:16:42 -0500 >> > From: Jim Crews <ji...@ms...> >> > >> > I'm a first time user of this list so I hope I'm addressing it to the >> > proper group. >> >> Actually, mak...@gn... is a better place. >> >> > I am trying to use the mingw32-make command on Windows 7, but receive an >> > error every time stating "*** multiple target patterns". I have no idea >> > what this means and have spent many hours online trying to find a >> > solution. >> > >> > My guess from everything I've read is that it has to do with the first >> > line >> > in my makefile: >> > >> > INC = -Ic:\GTK\include\gtk-2.0 >> > >> > MAIN = graphictest >> > OBJS = graphictest.o >> > >> > CC=gcc >> > CFLAGS = -Wall -g >> > >> > $(MAIN): $(MAIN) $(OBJS) $(INC) This is the real issue. Expand the variables and you'll see that $(INC) or $(INCLUDE) because it contains a : is causing make to look at it as multiple targets instead of one target. Remove the $(INC) or $(INCLUDE) from this line and give it another try. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Jim C. <ji...@ms...> - 2013-03-08 14:39:41
|
> Thanks so much for your response. As you may have guessed I'm new to > this, > > but am trying to set everything up so I can begin learning some C and > C++. > > > > I changed the variable name to INCLUDES (in case it conflicted with > > That doesn't matter. > > > something I didn't know about) and removed the -I. Same problem. I also > > tried the following formats for assigning the variable: > > > > INCLUDES = -I"c:\GTK\include\gtk-2.0" > > INCLUDES = -I'c:\GTK\include\gtk-2.0' > > INCLUDES = "c:\GTK\include\gtk-2.0" > > INCLUDES = c:\GTK\include\gtk-2.0 > > > > Ok, but ... > > > which resulted in the same error. If I change the path to exclude the c: > > then I get the "fatal error: gtk/gtk.h: No such file or directory" > > > > > > On Thu, Mar 7, 2013 at 4:41 PM, Eli Zaretskii <el...@gn...> wrote: > >> > >> > Date: Thu, 7 Mar 2013 16:16:42 -0500 > >> > From: Jim Crews <ji...@ms...> > >> > > >> > I'm a first time user of this list so I hope I'm addressing it to the > >> > proper group. > >> > >> Actually, mak...@gn... is a better place. > >> > >> > I am trying to use the mingw32-make command on Windows 7, but receive > an > >> > error every time stating "*** multiple target patterns". I have no > idea > >> > what this means and have spent many hours online trying to find a > >> > solution. > >> > > >> > My guess from everything I've read is that it has to do with the first > >> > line > >> > in my makefile: > >> > > >> > INC = -Ic:\GTK\include\gtk-2.0 > >> > > >> > MAIN = graphictest > >> > OBJS = graphictest.o > >> > > >> > CC=gcc > >> > CFLAGS = -Wall -g > >> > > >> > $(MAIN): $(MAIN) $(OBJS) $(INC) > > This is the real issue. Expand the variables and you'll see that > $(INC) or $(INCLUDE) because it contains a : is causing make to look > at it as multiple targets instead of one target. Remove the $(INC) or > $(INCLUDE) from this line and give it another try. > > Very sorry about the top post. As I said I'm new. I hope this response format is more appropriate. My problem is that when I remove the $(INC) then the header file I wish to include can no longer be found. So using this makefile: INCLUDES = -Ic:\GTK\include\gtk-2.0\gtk MAIN = graphictest OBJS = graphictest.o $(MAIN): $(MAIN) $(OBJS) I get a "fatal error: gtk/gtk.h: No such file or directory" I understand that the colon in the variable value is causing the problem, but I don't know how to specify the path to the include directory without using it. |
From: Keith M. <kei...@us...> - 2013-03-08 14:26:22
|
On 8 March 2013 13:51, Earnie Boyd <ea...@us...> wrote: > On Thu, Mar 7, 2013 at 5:16 PM, Jim Crews <ji...@ms...> wrote:>> > > >> > $(MAIN): $(MAIN) $(OBJS) $(INC) > > This is the real issue. Expand the variables and you'll see that > $(INC) or $(INCLUDE) because it contains a : is causing make to look > at it as multiple targets instead of one target. Remove the $(INC) or > $(INCLUDE) from this line and give it another try. > Also, since no one else seems to have noticed, I'll mention it: why does $(MAIN) depend on itself? $(MAIN) should not appear on the RHS here; $(INC), or the alternative $(INCLUDES), maybe should, (but without the -I flag). -- Regards, Keith. |
From: Eli Z. <el...@gn...> - 2013-03-08 14:41:53
|
> Date: Fri, 8 Mar 2013 08:51:51 -0500 > From: Earnie Boyd <ea...@us...> > > >> > $(MAIN): $(MAIN) $(OBJS) $(INC) > > This is the real issue. Expand the variables and you'll see that > $(INC) or $(INCLUDE) because it contains a : is causing make to look > at it as multiple targets instead of one target. Not if the expansion is like this: graphictest: graphictest.o c:\GTK\include\gtk-2.0 The MinGW build of Make already knows that "c:" at the beginning of a prerequisite name is the drive letter. (Btw, why is $(MAIN) both to the left and to the right of the colon? This is circular dependency, and it doesn't make any sense.) |
From: Eli Z. <el...@gn...> - 2013-03-08 14:55:19
|
> Date: Fri, 8 Mar 2013 09:39:19 -0500 > From: Jim Crews <ji...@ms...> > > My problem is that when I remove the $(INC) then the header file I wish to > include can no longer be found. So using this makefile: > > INCLUDES = -Ic:\GTK\include\gtk-2.0\gtk > > MAIN = graphictest > OBJS = graphictest.o > > $(MAIN): $(MAIN) $(OBJS) > > I get a "fatal error: gtk/gtk.h: No such file or directory" The -Ic:\GTK\include\gtk-2.0\gtk switch should go into CPPFLAGS. |
From: Earnie B. <ea...@us...> - 2013-03-08 18:49:00
|
On Fri, Mar 8, 2013 at 9:26 AM, Keith Marshall wrote: > $(INC), or the alternative $(INCLUDES), maybe should, > (but without the -I flag). Regardless of the -l flag the : is causing a multi-target to be defined. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Keith M. <kei...@us...> - 2013-03-08 22:16:14
|
On 08/03/13 18:48, Earnie Boyd wrote: > On Fri, Mar 8, 2013 at 9:26 AM, Keith Marshall wrote: >> $(INC), or the alternative $(INCLUDES), maybe should, >> (but without the -I flag). > > Regardless of the -l flag the : is causing a multi-target to be defined. Well, both Eli and I would beg to disagree with this assertion; this, I think, must conclusively refute it: $ cat Makefile foo: c:\mingw\foo.c echo $@ $ mingw32-make mingw32-make: *** No rule to make target 'c:\mingw\foo.c', needed by 'foo'. Stop. $ touch /c/mingw/foo.c $ mingw32-make echo foo foo -- Regards, Keith. |
From: Eli Z. <el...@gn...> - 2013-03-09 08:14:39
|
> Date: Fri, 08 Mar 2013 22:16:03 +0000 > From: Keith Marshall <kei...@us...> > > On 08/03/13 18:48, Earnie Boyd wrote: > > On Fri, Mar 8, 2013 at 9:26 AM, Keith Marshall wrote: > >> $(INC), or the alternative $(INCLUDES), maybe should, > >> (but without the -I flag). > > > > Regardless of the -l flag the : is causing a multi-target to be defined. > > Well, both Eli and I would beg to disagree with this assertion; this, I > think, must conclusively refute it: Indeed. There's code in Make, which I wrote, that takes care of detecting file names with drive letters correctly. But this happens only if the "x:" drive letter string immediately follows a delimiter, such as a blank character. It will not work in "-Ic:\foo" situation. That's because there are (ugly, but correct) Makefile's there which use something like this: foo:/bar do_something and you don't want Make to decide that o:/bar is a reference to a Windows file name in this case. |
From: Earnie B. <ea...@us...> - 2013-03-09 14:23:11
|
On Fri, Mar 8, 2013 at 5:16 PM, Keith Marshall wrote: > On 08/03/13 18:48, Earnie Boyd wrote: >> On Fri, Mar 8, 2013 at 9:26 AM, Keith Marshall wrote: >>> $(INC), or the alternative $(INCLUDES), maybe should, >>> (but without the -I flag). >> >> Regardless of the -l flag the : is causing a multi-target to be defined. > > Well, both Eli and I would beg to disagree with this assertion; this, I > think, must conclusively refute it: > Okay, I misinterpreted the error message. Jim has violated the static pattern rules. http://www.gnu.org/software/make/manual/html_node/Static-Usage.html#Static-Usage -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Keith M. <kei...@us...> - 2013-03-09 19:17:46
|
On 09/03/13 14:23, Earnie Boyd wrote: > On Fri, Mar 8, 2013 at 5:16 PM, Keith Marshall wrote: >> On 08/03/13 18:48, Earnie Boyd wrote: >>> On Fri, Mar 8, 2013 at 9:26 AM, Keith Marshall wrote: >>>> $(INC), or the alternative $(INCLUDES), maybe should, >>>> (but without the -I flag). >>> >>> Regardless of the -l flag the : is causing a multi-target to be defined. >> >> Well, both Eli and I would beg to disagree with this assertion; this, I >> think, must conclusively refute it: > > Okay, I misinterpreted the error message. Jim has violated the static > pattern rules. Sorry, but I just don't see how this is relevant. We have a saying in Britain: when you're in a hole, stop digging. Jim's usage doesn't even remotely resemble a static pattern rule. The actual issue is that he has tried to introduce an INCLUDES path spec as a dependency, which it isn't. It belongs within the commands section of the rule, where it would be logically introduced via CPPFLAGS; it has no place as a pre-requisite of the target. Eli has already correctly diagnosed the issue, and stated the solution; there's really no need to confuse matters, by continuing to pursue any more blind alleys. -- Regards, Keith. |
From: Earnie B. <ea...@us...> - 2013-03-09 22:14:31
|
On Sat, Mar 9, 2013 at 2:17 PM, Keith Marshall wrote: > On 09/03/13 14:23, Earnie Boyd wrote: >> On Fri, Mar 8, 2013 at 5:16 PM, Keith Marshall wrote: >>> On 08/03/13 18:48, Earnie Boyd wrote: >>>> On Fri, Mar 8, 2013 at 9:26 AM, Keith Marshall wrote: >>>>> $(INC), or the alternative $(INCLUDES), maybe should, >>>>> (but without the -I flag). >>>> >>>> Regardless of the -l flag the : is causing a multi-target to be defined. >>> >>> Well, both Eli and I would beg to disagree with this assertion; this, I >>> think, must conclusively refute it: >> >> Okay, I misinterpreted the error message. Jim has violated the static >> pattern rules. > > Sorry, but I just don't see how this is relevant. We have a saying in > Britain: when you're in a hole, stop digging. > I'm still digging. > Jim's usage doesn't even remotely resemble a static pattern rule. ~~~~~ > INC = -Ic:\GTK\include\gtk-2.0 > > MAIN = graphictest > OBJS = graphictest.o > > CC=gcc > CFLAGS = -Wall -g > > $(MAIN): $(MAIN) $(OBJS) $(INC) ~~~~~ graphictest: graphictest graphictest.o -lc:\GTK\include\gtk-2.0 Based on: ~~~~~ Here is the syntax of a static pattern rule: targets ...: target-pattern: prereq-patterns ... recipe ... ~~~~~ The error: ~~~~~ "*** multiple target patterns" ~~~~~ is given. See http://www.gnu.org/software/make/manual/html_node/Error-Messages.html which states ~~~~~ ‘missing target pattern. Stop.’ ‘multiple target patterns. Stop.’ ‘target pattern contains no `%'. Stop.’ ‘mixed implicit and static pattern rules. Stop.’ These are generated for malformed static pattern rules. The first means there's no pattern in the target section of the rule; the second means there are multiple patterns in the target section; the third means the target doesn't contain a pattern character (%); and the fourth means that all three parts of the static pattern rule contain pattern characters (%)–only the first two parts should. See Syntax of Static Pattern Rules. ~~~~~ > The > actual issue is that he has tried to introduce an INCLUDES path spec as > a dependency, which it isn't. It belongs within the commands section of > the rule, where it would be logically introduced via CPPFLAGS; it has no > place as a pre-requisite of the target. > I don't disagree that this is wrong use. The error message is given is due to incorrect static patterns however but that in itself was given because of the wrong use. > Eli has already correctly diagnosed the issue, and stated the solution; > there's really no need to confuse matters, by continuing to pursue any > more blind alleys. > Yes, I went to the documentation to clear up my confusion. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Keith M. <kei...@us...> - 2013-03-10 16:31:18
|
Off topic philosophical note on inappropriate "expert" advice, resulting from misdiagnosis of original issue. On 09/03/13 22:14, Earnie Boyd wrote: > On Sat, Mar 9, 2013 at 2:17 PM, Keith Marshall wrote: >> On 09/03/13 14:23, Earnie Boyd wrote: >>> On Fri, Mar 8, 2013 at 5:16 PM, Keith Marshall wrote: >>>> On 08/03/13 18:48, Earnie Boyd wrote: >>>>> On Fri, Mar 8, 2013 at 9:26 AM, Keith Marshall wrote: >>>>>> $(INC), or the alternative $(INCLUDES), maybe should, >>>>>> (but without the -I flag). >>>>> >>>>> Regardless of the -l flag the : is causing a multi-target to be defined. >>>> >>>> Well, both Eli and I would beg to disagree with this assertion; this, I >>>> think, must conclusively refute it: >>> >>> Okay, I misinterpreted the error message. Jim has violated the static >>> pattern rules. >> >> Sorry, but I just don't see how this is relevant. We have a saying in >> Britain: when you're in a hole, stop digging. >> > > I'm still digging. And, in so doing, deepening the confusion even further. >> Jim's usage doesn't even remotely resemble a static pattern rule. > > ~~~~~ >> INC = -Ic:\GTK\include\gtk-2.0 >> >> MAIN = graphictest >> OBJS = graphictest.o >> >> CC=gcc >> CFLAGS = -Wall -g >> >> $(MAIN): $(MAIN) $(OBJS) $(INC) > ~~~~~ > > graphictest: graphictest graphictest.o -lc:\GTK\include\gtk-2.0 This isn't a pattern rule, static or otherwise; it is simply a malformed dependency specification. > Based on: > > ~~~~~ > Here is the syntax of a static pattern rule: > > targets ...: target-pattern: prereq-patterns ... > recipe > ... > ~~~~~ > > The error: > > ~~~~~ > "*** multiple target patterns" > ~~~~~ > > is given. I don't disagree that, ON A POSIX SYSTEM, this message would normally indicate a malformed static pattern rule. In this case, however, we are responding to an enquiry relating to a MS-WINDOWS SYSTEM; make itself is confused by a malformed DEPENDENCY SPECIFICATION, and as a consequence of this confusion, is issuing a bogus and irrelevant error message. While it may be interesting to understand why make emits this bogus message, it doesn't assist in the diagnosis of the original issue. > See http://www.gnu.org/software/make/manual/html_node/Error-Messages.html > which states > > ~~~~~ > ‘missing target pattern. Stop.’ > ‘multiple target patterns. Stop.’ Yes, this is the message make spewed out; it could just as well... > ‘target pattern contains no `%'. Stop.’ ...have issued this one; (indeed, it would have done so, had there been no other dependency specifications preceding the malformed one, and this might have been slightly more enlightening). However, either message is based on make's best guess regarding the user's intent, and that guess, while understandable, was wrong). > ‘mixed implicit and static pattern rules. Stop.’ > These are generated for malformed static pattern rules. The first > means there's no pattern in the target section of the rule; the second > means there are multiple patterns in the target section; the third > means the target doesn't contain a pattern character (%); and the > fourth means that all three parts of the static pattern rule contain > pattern characters (%)–only the first two parts should. See Syntax of > Static Pattern Rules. > ~~~~~ > >> The >> actual issue is that he has tried to introduce an INCLUDES path spec as >> a dependency, which it isn't. It belongs within the commands section of >> the rule, where it would be logically introduced via CPPFLAGS; it has no >> place as a pre-requisite of the target. >> > > I don't disagree that this is wrong use. The error message is given > is due to incorrect static patterns ... No, it has nothing to do with static patterns. Let's face it, static pattern rules are a fairly advanced aspect of GNU make. In around 25 years of using make, (not always the GNU variant), I can't recall any instance where I have used one; it is improbable that the OP (Jim), a self-proclaimed novice, is even aware of the concept of static pattern rules, much less trying to write one. Is it fair that you and I, who should be sufficiently expert to identify this misdiagnosis by make, should throw this discussion of an irrelevant advanced concept into the analysis of the OP's issue? I don't think it is. > ... however but that in itself was given because of the wrong use. Yes, the usage was wrong, and I've no doubt that your analysis of why it resulted in that particular message is accurate. However, the fact remains that you've introduced a side issue into the discussion, (and an extremely advanced side issue which is not germane to the OP's problem); the thread would have been better left... >> Eli has already correctly diagnosed the issue, and stated the solution; ...here. >> there's really no need to confuse matters, by continuing to pursue any >> more blind alleys. > > Yes, I went to the documentation to clear up my confusion. You've satisfied your curiosity, on a side issue. However, I suspect that, by introducing this red herring, and dogmatically pounding on about it, you may have left the OP, (and any number of less experienced users), deeply confused, (if indeed, they didn't give up even trying to follow the diversion, long ago). -- Regards, Keith. |
From: Jim C. <ji...@ms...> - 2013-03-10 21:36:07
|
Well, I'm not giving up yet, although some of you probably wish I would. Sorry that my poorly-formed makefile caused such confusion. For what it's worth I sincerely appreciate experts being willing to help out those of us who are new. > > You've satisfied your curiosity, on a side issue. However, I suspect > that, by introducing this red herring, and dogmatically pounding on > about it, you may have left the OP, (and any number of less experienced > users), deeply confused, (if indeed, they didn't give up even trying to > follow the diversion, long ago). > BUT, from everything I've read in this thread I understand that a makefile with a single line as follows: graphictest: graphictest.o c:\GTK\include\gtk-2.0\gtk SHOULD work, yes? The good news is that running it doesn't generate the "multiple target patterns" error but it does generate the "No such file or directory" error. Now even I can figure out what that's supposed to mean, but the file I'm trying to include in my C program (#include <gtk.h>) IS in that directory. Am I still doing something wrong here? |
From: Keith M. <kei...@us...> - 2013-03-10 22:10:52
|
On 10/03/13 21:35, Jim Crews wrote: > BUT, from everything I've read in this thread I understand that a makefile > with a single line as follows: > > graphictest: graphictest.o c:\GTK\include\gtk-2.0\gtk > > SHOULD work, yes? Yes. And no. > The good news is that running it doesn't generate the > "multiple target patterns" error ... Because now you've eliminate the malformed dependency specification, which was the cause of that error message; in this respect, now that specification "works". However ... > but it does generate the "No such file or > directory" error. Now even I can figure out what that's supposed to mean, > but the file I'm trying to include in my C program (#include <gtk.h>) IS in > that directory. Am I still doing something wrong here? Yes, you are; at least two things, that I can see, in this line alone: 1) On Windows, an executable file bears a .exe extension; make needs to be told that, otherwise the target isn't created by the default rule. (Since you don't show any commands associated with your dependency specification, I'm assuming that you are relying on the default rules, both to compile the graphictest.o from graphictest.c, and subsequently to link graphictest.o to make graphictest.exe). Your dependency rule should be: graphictest.exe: graphictest.o ... 2) The *directory* c:\GTK\include\gtk-2.0\gtk is the header include directory for your GTK headers; it is *not* a pre-requisite of your executable, (nor even of your .o files), and should *not* appear in *any* dependency specification. It should be specified in a context where it will appear, prefixed by the -I flag, in the *commands* which are to be executed when your .c, (or .cpp), file is compiled. Since you appear to be relying on the default compile rule, the appropriate way to get it into that context is to add your $(INC) to CPPFLAGS. -- Regards, Keith. |
From: Peter R. <pe...@ly...> - 2013-03-10 23:27:43
|
On 2013-03-10 22:35, Jim Crews wrote: > Well, I'm not giving up yet, although some of you probably wish I would. Sorry that my poorly-formed makefile caused such confusion. For what it's worth I sincerely appreciate experts being willing to help out those of us who are new. > > > > You've satisfied your curiosity, on a side issue. However, I suspect > that, by introducing this red herring, and dogmatically pounding on > about it, you may have left the OP, (and any number of less experienced > users), deeply confused, (if indeed, they didn't give up even trying to > follow the diversion, long ago). > > > BUT, from everything I've read in this thread I understand that a makefile with a single line as follows: > > graphictest: graphictest.o c:\GTK\include\gtk-2.0\gtk > > SHOULD work, yes? The good news is that running it doesn't generate the "multiple target patterns" error but it does generate the "No such file or directory" error. Now even I can figure out what that's supposed to mean, but the file I'm trying to include in my C program (#include <gtk.h>) IS in that directory. Am I still doing something wrong here? A line like foo: bar gazonk tells make that foo depends on bar and gazonk, nothing more. It tells nothing about how bar and gazonk affects foo. I.e. this is not how one adds extra object files when linking or additional include directories when compiling. The "how" part is often stated on the lines below the dependency line, but equally often (as in your case) it is from some pattern rule, which may be implicit (as in your case). Cheers, Peter |
From: Eli Z. <el...@gn...> - 2013-03-10 22:08:34
|
> Date: Sun, 10 Mar 2013 17:35:59 -0400 > From: Jim Crews <ji...@ms...> > > BUT, from everything I've read in this thread I understand that a makefile > with a single line as follows: > > graphictest: graphictest.o c:\GTK\include\gtk-2.0\gtk > > SHOULD work, yes? Yes. > The good news is that running it doesn't generate the > "multiple target patterns" error but it does generate the "No such file or > directory" error. Now even I can figure out what that's supposed to mean, > but the file I'm trying to include in my C program (#include <gtk.h>) IS in > that directory. Am I still doing something wrong here? Yes. If you want graphictest the program to depend on gtk.h header file, you need to tell precisely that to Make, like this: graphictest: graphictest.o c:\GTK\include\gtk-2.0\gtk\gtk.h IOW, the prerequisite is the header file, not its parent directory. (I hope I understood correctly what is the full name of that header file; if not, adjust the file name accordingly.) |
From: Jim C. <ji...@ms...> - 2013-03-11 01:14:44
|
On Sun, Mar 10, 2013 at 6:07 PM, Eli Zaretskii <el...@gn...> wrote: > > Date: Sun, 10 Mar 2013 17:35:59 -0400 > > From: Jim Crews <ji...@ms...> > > > > BUT, from everything I've read in this thread I understand that a > makefile > > with a single line as follows: > > > > graphictest: graphictest.o c:\GTK\include\gtk-2.0\gtk > > > > SHOULD work, yes? > > Yes. > > > The good news is that running it doesn't generate the > > "multiple target patterns" error but it does generate the "No such file > or > > directory" error. Now even I can figure out what that's supposed to > mean, > > but the file I'm trying to include in my C program (#include <gtk.h>) IS > in > > that directory. Am I still doing something wrong here? > > Yes. If you want graphictest the program to depend on gtk.h header > file, you need to tell precisely that to Make, like this: > > graphictest: graphictest.o c:\GTK\include\gtk-2.0\gtk\gtk.h > > IOW, the prerequisite is the header file, not its parent directory. > (I hope I understood correctly what is the full name of that header > file; if not, adjust the file name accordingly.) > > > Thank you - that makes sense to me. But after changing the line to be more explicit (like you stated) I still get the not found error. |
From: Keith M. <kei...@us...> - 2013-03-11 08:00:59
|
On 11/03/13 01:14, Jim Crews wrote: > Thank you - that makes sense to me. But after changing the line to be > more explicit (like you stated) I still get the not found error. That's because you're still telling make that the header file is a pre-requisite for linking the executable, which it is not. It may be, (apparently is), a pre-requisite for *compiling* the object file, but you didn't` tell make that. You need to either: 1) Declare the object <-- header dependency explicitly, or 2) Add the header include path to CPPFLAGS, (as you've already been advised several times now), so that the compiler can locate the header file implicitly. Option (2) is the normal, and likely the better, choice. -- Regards, Keith. |
From: Eli Z. <el...@gn...> - 2013-03-11 03:45:02
|
> Date: Sun, 10 Mar 2013 21:14:36 -0400 > From: Jim Crews <ji...@ms...> > > Thank you - that makes sense to me. But after changing the line to be > more explicit (like you stated) I still get the not found error. Please show the exact error message(s) you see. I suspect the message comes from the compiler, not from Make, which means you moved on to the next problem in your Makefile. |