Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #73834 > unrolled thread
| Started by | Alla _ <modelling.data@gmail.com> |
|---|---|
| First post | 2015-10-26 03:09 -0700 |
| Last post | 2015-10-26 10:43 -0700 |
| Articles | 20 on this page of 115 — 21 participants |
Back to article view | Back to comp.lang.c
Program to output initials of a name Alla _ <modelling.data@gmail.com> - 2015-10-26 03:09 -0700
Re: Program to output initials of a name Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-26 03:22 -0700
Re: Program to output initials of a name Alla _ <modelling.data@gmail.com> - 2015-10-26 05:32 -0700
Re: Program to output initials of a name Barry Schwarz <schwarzb@dqel.com> - 2015-10-26 14:34 -0700
Re: Program to output initials of a name Richard Heathfield <rjh@cpax.org.uk> - 2015-10-26 10:38 +0000
Re: Program to output initials of a name Alla _ <modelling.data@gmail.com> - 2015-10-26 05:37 -0700
Re: Program to output initials of a name Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-26 13:53 +0000
Re: Program to output initials of a name Alla _ <modelling.data@gmail.com> - 2015-10-26 07:33 -0700
Re: Program to output initials of a name Richard Heathfield <rjh@cpax.org.uk> - 2015-10-26 15:21 +0000
Re: Program to output initials of a name Bartc <bc@freeuk.com> - 2015-10-26 16:26 +0000
Re: Program to output initials of a name Richard Heathfield <rjh@cpax.org.uk> - 2015-10-26 16:41 +0000
Re: Program to output initials of a name Geoff <geoff@invalid.invalid> - 2015-10-26 10:27 -0700
Re: Program to output initials of a name Bartc <bc@freeuk.com> - 2015-10-26 17:29 +0000
Re: Program to output initials of a name raltbos@xs4all.nl (Richard Bos) - 2015-11-10 15:40 +0000
Re: Program to output initials of a name Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-27 13:36 +0000
Re: Program to output initials of a name Richard Heathfield <rjh@cpax.org.uk> - 2015-10-27 13:45 +0000
Re: Program to output initials of a name David Brown <david.brown@hesbynett.no> - 2015-10-27 15:10 +0100
Re: Program to output initials of a name Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-27 20:08 +0000
Re: Program to output initials of a name David Brown <david.brown@hesbynett.no> - 2015-10-27 22:28 +0100
Re: Program to output initials of a name Bartc <bc@freeuk.com> - 2015-10-27 21:34 +0000
Re: Program to output initials of a name David Brown <david.brown@hesbynett.no> - 2015-10-28 08:50 +0100
Re: Program to output initials of a name Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-28 15:19 +0000
Re: Program to output initials of a name David Brown <david.brown@hesbynett.no> - 2015-10-28 22:17 +0100
Re: Program to output initials of a name Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-29 19:54 +0000
Re: Program to output initials of a name David Brown <david.brown@hesbynett.no> - 2015-10-30 08:44 +0100
Re: Program to output initials of a name James Kuyper <jameskuyper@verizon.net> - 2015-10-30 13:44 -0400
Re: Program to output initials of a name guinness.tony@gmail.com - 2015-10-28 04:19 -0700
Re: Program to output initials of a name David Brown <david.brown@hesbynett.no> - 2015-10-28 12:50 +0100
Re: Program to output initials of a name guinness.tony@gmail.com - 2015-10-28 08:19 -0700
Re: Program to output initials of a name guinness.tony@gmail.com - 2015-10-28 10:21 -0700
Re: Program to output initials of a name David Brown <david.brown@hesbynett.no> - 2015-10-28 22:34 +0100
Re: Program to output initials of a name raltbos@xs4all.nl (Richard Bos) - 2015-11-10 15:50 +0000
Re: Program to output initials of a name Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-27 14:13 +0000
Re: Program to output initials of a name Richard Heathfield <rjh@cpax.org.uk> - 2015-10-27 14:15 +0000
Re: Program to output initials of a name Keith Thompson <kst-u@mib.org> - 2015-10-27 08:59 -0700
Re: Program to output initials of a name Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-27 21:34 +0000
Re: Program to output initials of a name James Kuyper <jameskuyper@verizon.net> - 2015-10-27 12:09 -0400
Re: Program to output initials of a name Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-27 20:03 +0000
Re: Program to output initials of a name James Kuyper <jameskuyper@verizon.net> - 2015-10-27 19:36 -0400
Re: Program to output initials of a name David Brown <david.brown@hesbynett.no> - 2015-10-28 09:06 +0100
Re: Program to output initials of a name Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-28 12:28 +0000
Re: Program to output initials of a name Geoff <geoff@invalid.invalid> - 2015-10-26 10:15 -0700
Re: Program to output initials of a name Ian Collins <ian-news@hotmail.com> - 2015-10-27 07:34 +1300
Re: Program to output initials of a name Richard Heathfield <rjh@cpax.org.uk> - 2015-10-26 18:40 +0000
Re: Program to output initials of a name Bartc <bc@freeuk.com> - 2015-10-26 19:00 +0000
Re: Program to output initials of a name Ian Collins <ian-news@hotmail.com> - 2015-10-27 08:53 +1300
Re: Program to output initials of a name Bartc <bc@freeuk.com> - 2015-10-26 20:41 +0000
Re: Program to output initials of a name Ian Collins <ian-news@hotmail.com> - 2015-10-27 10:24 +1300
Re: Program to output initials of a name Keith Thompson <kst-u@mib.org> - 2015-10-26 16:06 -0700
Re: Program to output initials of a name Ian Collins <ian-news@hotmail.com> - 2015-10-27 13:16 +1300
Re: Program to output initials of a name Keith Thompson <kst-u@mib.org> - 2015-10-27 08:46 -0700
Re: Program to output initials of a name Ian Collins <ian-news@hotmail.com> - 2015-10-28 07:25 +1300
Re: Program to output initials of a name raltbos@xs4all.nl (Richard Bos) - 2015-11-10 15:52 +0000
Re: Program to output initials of a name Richard Heathfield <rjh@cpax.org.uk> - 2015-10-27 02:15 +0000
Re: Program to output initials of a name Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-26 19:28 -0700
Re: Program to output initials of a name Richard Heathfield <rjh@cpax.org.uk> - 2015-10-27 02:39 +0000
Re: Program to output initials of a name Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-27 02:59 -0700
Re: Program to output initials of a name Richard Heathfield <rjh@cpax.org.uk> - 2015-10-27 10:24 +0000
Re: Program to output initials of a name Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-27 03:57 -0700
Re: Program to output initials of a name Richard Heathfield <rjh@cpax.org.uk> - 2015-10-27 11:09 +0000
Re: Program to output initials of a name Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-27 11:23 +0000
Re: Program to output initials of a name Richard Heathfield <rjh@cpax.org.uk> - 2015-10-27 11:28 +0000
Re: Program to output initials of a name Bartc <bc@freeuk.com> - 2015-10-27 11:37 +0000
Re: Program to output initials of a name Richard Heathfield <rjh@cpax.org.uk> - 2015-10-27 11:46 +0000
Re: Program to output initials of a name Bartc <bc@freeuk.com> - 2015-10-27 11:50 +0000
Re: Program to output initials of a name supercat@casperkitty.com - 2015-10-27 08:44 -0700
Re: Program to output initials of a name Bartc <bc@freeuk.com> - 2015-10-27 11:19 +0000
Re: Program to output initials of a name Richard Heathfield <rjh@cpax.org.uk> - 2015-10-27 11:25 +0000
Re: Program to output initials of a name Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-28 14:24 +0000
Re: Program to output initials of a name James Kuyper <jameskuyper@verizon.net> - 2015-10-26 14:00 -0400
Re: Program to output initials of a name Ian Collins <ian-news@hotmail.com> - 2015-10-27 11:00 +1300
Re: Program to output initials of a name Lowell Gilbert <lgusenet@be-well.ilk.org> - 2015-10-27 15:39 -0400
Re: Program to output initials of a name Keith Thompson <kst-u@mib.org> - 2015-10-26 10:17 -0700
Re: Program to output initials of a name Alla _ <modelling.data@gmail.com> - 2015-10-26 10:28 -0700
Re: Program to output initials of a name Bartc <bc@freeuk.com> - 2015-10-26 10:43 +0000
Re: Program to output initials of a name Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-26 03:52 -0700
Re: Program to output initials of a name Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-27 13:11 +0000
Re: Program to output initials of a name David Brown <david.brown@hesbynett.no> - 2015-10-27 15:14 +0100
[OT] family naming conventions James Kuyper <jameskuyper@verizon.net> - 2015-10-27 12:01 -0400
Re: [OT] family naming conventions Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-10-27 13:17 -0600
Re: [OT] family naming conventions Siri Cruz <chine.bleu@yahoo.com> - 2015-10-27 13:55 -0700
Re: [OT] family naming conventions Robert Wessel <robertwessel2@yahoo.com> - 2015-10-27 17:59 -0500
Re: [OT] family naming conventions raltbos@xs4all.nl (Richard Bos) - 2015-11-10 15:56 +0000
Re: [OT] family naming conventions James Kuyper <jameskuyper@verizon.net> - 2015-11-10 11:41 -0500
Re: [OT] family naming conventions raltbos@xs4all.nl (Richard Bos) - 2015-11-10 19:00 +0000
Re: [OT] family naming conventions James Kuyper <jameskuyper@verizon.net> - 2015-11-10 14:11 -0500
Re: [OT] family naming conventions raltbos@xs4all.nl (Richard Bos) - 2015-11-10 21:19 +0000
Re: [OT] family naming conventions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-10 13:32 -0800
Re: [OT] family naming conventions raltbos@xs4all.nl (Richard Bos) - 2015-11-13 21:38 +0000
Re: [OT] family naming conventions Udyant Wig <udyantw@gmail.com> - 2015-11-11 15:47 +0530
Re: [OT] family naming conventions raltbos@xs4all.nl (Richard Bos) - 2015-11-13 21:36 +0000
Re: Program to output initials of a name Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-27 08:50 -0700
Re: Program to output initials of a name Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-27 16:23 +0000
Re: Program to output initials of a name Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-27 10:06 -0700
Re: Program to output initials of a name Alla _ <modelling.data@gmail.com> - 2015-10-26 05:40 -0700
Re: Program to output initials of a name Udyant Wig <udyantw@gmail.com> - 2015-10-26 16:20 +0530
Re: Program to output initials of a name Bartc <bc@freeuk.com> - 2015-10-26 10:55 +0000
Re: Program to output initials of a name Keith Thompson <kst-u@mib.org> - 2015-10-26 10:20 -0700
Re: Program to output initials of a name Bartc <bc@freeuk.com> - 2015-10-26 17:36 +0000
Re: Program to output initials of a name Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-28 16:54 -0700
Re: Program to output initials of a name Bartc <bc@freeuk.com> - 2015-10-29 00:50 +0000
Re: Program to output initials of a name Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-30 08:18 -0700
Re: Program to output initials of a name Barry Schwarz <schwarzb@dqel.com> - 2015-10-26 06:15 -0700
Re: Program to output initials of a name Alla _ <modelling.data@gmail.com> - 2015-10-26 09:42 -0700
Re: Program to output initials of a name Keith Thompson <kst-u@mib.org> - 2015-10-26 11:20 -0700
Re: Program to output initials of a name Alla _ <modelling.data@gmail.com> - 2015-10-26 09:44 -0700
Re: Program to output initials of a name Keith Thompson <kst-u@mib.org> - 2015-10-26 11:21 -0700
Re: Program to output initials of a name Alla _ <modelling.data@gmail.com> - 2015-10-26 09:47 -0700
Re: Program to output initials of a name Alla _ <modelling.data@gmail.com> - 2015-10-26 10:47 -0700
Re: Program to output initials of a name Richard Heathfield <rjh@cpax.org.uk> - 2015-10-26 18:20 +0000
Re: Program to output initials of a name Alla _ <modelling.data@gmail.com> - 2015-10-26 11:56 -0700
Re: Program to output initials of a name Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-26 19:24 +0000
Re: Program to output initials of a name Alla _ <modelling.data@gmail.com> - 2015-10-26 12:01 -0700
Re: Program to output initials of a name Richard Heathfield <rjh@cpax.org.uk> - 2015-10-26 17:48 +0000
Re: Program to output initials of a name Keith Thompson <kst-u@mib.org> - 2015-10-26 10:43 -0700
Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-10-28 08:50 +0100 |
| Message-ID | <n0puk6$nlj$1@dont-email.me> |
| In reply to | #74018 |
On 27/10/15 22:34, Bartc wrote: > On 27/10/2015 21:28, David Brown wrote: > >> The OP has probably given up on the thread by this point - but if not, >> then I hope it will help. Maybe it will also help Bart see that >> Makefiles are not as scary as he imagines. > > I don't intend to ever use make files for my own development, which is > highly non-standard anyway. > > So I mainly come across them when trying to build other people's > projects. And usually they don't work (for reasons I've mentioned enough > times). > Perhaps the example I gave you might help you understand that Makefiles /can/ be simple, can work perfectly well, and can be a useful and practical tool for other people. If you don't want to use them yourself, that's fine - it's your loss, not mine. But if it shows you that using "make" does not mean learning a whole new language, or archaic tools that only work on Linux, then progress will have been made.
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2015-10-28 15:19 +0000 |
| Message-ID | <slrnn31prr.5q5.grahn+nntp@frailea.sa.invalid> |
| In reply to | #74016 |
On Tue, 2015-10-27, David Brown wrote:
> On 27/10/15 21:08, Jorgen Grahn wrote:
>> On Tue, 2015-10-27, David Brown wrote:
>>> On 27/10/15 14:36, Jorgen Grahn wrote:
...
>>>> Why would you want to do that when you can just write the Makefile
>>>> manually?
>>>>
>>>> CFLAGS=-W -Wall -pedantic -std=c99
>>>> foo: foo.o
>>>> $(CC) $(CFLAGS) -o $@ $^
>>>>
>>>> That should be all needed for a one-file program.
>>>>
>>>
>>> (foo.o should be foo.c)
>>
>> No, that was intentional. The "foo: foo.o" above just does the
>> linking, and there's an implicit rule (or whatever the term for it is)
>> which provides "foo.o: foo.c". With GNU Make at least.
>>
>
> OK. Since almost all my C programming is for embedded systems, and
> therefore uses a compiler other than the system standard, I always have
> the compiler and it's calls given explicitly. So I completely forgot
> about the implicit rules, as I don't use them.
That doesn't really make implicit rules useless. For example, if your
compiler isn't called gcc, just change $(CC).
Even if the whole builtin implicit rule (%.o: %.c or whatever it is)
doesn't apply, I think it probably simplifies your Makefile if you
write your own implicit rules. Untested example:
obj-arm/%.o: %.c
$(CC) ... etc
test/%.o: test/%.c
$(CC) ... etc
In most of my Makefiles
- the link step links a main.o and a libfoo.a
- the archiver creates libfoo.a from a bunch of object files
... and I never need to mention the source files themselves. (Almost
never. Sometimes I do anyway, when a specific file needs a different
compiler flag.)
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-10-28 22:17 +0100 |
| Message-ID | <n0rdt5$gln$1@dont-email.me> |
| In reply to | #74084 |
On 28/10/15 16:19, Jorgen Grahn wrote: > On Tue, 2015-10-27, David Brown wrote: >> On 27/10/15 21:08, Jorgen Grahn wrote: >>> On Tue, 2015-10-27, David Brown wrote: >>>> On 27/10/15 14:36, Jorgen Grahn wrote: > ... >>>>> Why would you want to do that when you can just write the Makefile >>>>> manually? >>>>> >>>>> CFLAGS=-W -Wall -pedantic -std=c99 >>>>> foo: foo.o >>>>> $(CC) $(CFLAGS) -o $@ $^ >>>>> >>>>> That should be all needed for a one-file program. >>>>> >>>> >>>> (foo.o should be foo.c) >>> >>> No, that was intentional. The "foo: foo.o" above just does the >>> linking, and there's an implicit rule (or whatever the term for it is) >>> which provides "foo.o: foo.c". With GNU Make at least. >>> >> >> OK. Since almost all my C programming is for embedded systems, and >> therefore uses a compiler other than the system standard, I always have >> the compiler and it's calls given explicitly. So I completely forgot >> about the implicit rules, as I don't use them. > > That doesn't really make implicit rules useless. For example, if your > compiler isn't called gcc, just change $(CC). > It is true that some of the implicit rules could be used in this manner - but so few would suit my needs that it is not worth the effort. There are too many things I want to specialise. For example, in my current project, a compilation line actually looks like this: /opt/Freescale/KDS_2.0.0/toolchain/bin/arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16 -c -std=gnu11 -Wa,--no-warn -Wbad-function-cast -Wpointer-sign -fsigned-char -ffunction-sections -fdata-sections -fmessage-length=0 -ffast-math -fverbose-asm -frecord-gcc-switches -Wa,-adchlsgn=release/lst/src/main/doser.lst -O2 -fmerge-all-constants -finline-small-functions -findirect-inlining -fpartial-inlining -fgcse-sm -fgcse-las -fgcse-after-reload -fsee -fschedule-insns -fhoist-adjacent-loads -ftree-pre -ftree-builtin-call-dce -ftree-loop-im -ftree-loop-ivcanon -fivopts -ftree-vrp -freorder-blocks -fpredictive-commoning -fipa-pta -ftree-tail-merge -fweb -fsection-anchors -Wall -Wdouble-promotion -Winit-self -Wuninitialized -Wmissing-include-dirs -Wfloat-equal -Wpointer-arith -Wwrite-strings -Wlogical-op -Wtrampolines -Wdisabled-optimization -Wunreachable-code -Winvalid-pch -Wno-multichar -Wno-main -Wno-address -Wno-unused-but-set-variable -Wno-unused-variable -isystem src/includes -isystem src/configs -isystem src/includes/device -isystem src/drivers -isystem src/lwip/src/include -isystem src/lwip/port -isystem src/lwip/src/include/lwip -isystem src/lwip/port/arch -isystem src/lwip/src/include/ipv4 -isystem src/board -g3 -Wextra -Wmissing-field-initializers -Wunused-parameter -Wredundant-decls -Wmissing-declarations -Winline -Wswitch-enum -Wmissing-noreturn -Wmissing-format-attribute -Wsuggest-attribute=pure -Wsuggest-attribute=const -Wunsafe-loop-optimizations -Wstrict-overflow -Wsuggest-attribute=noreturn -Wcast-qual -Wcast-align -Wunused -Waddress -Wshadow -Wunused-but-set-variable -Wunused-variable -Wno-sign-compare -Wundef -Wpadded -Wnested-externs -Wmissing-prototypes -Wc++-compat -Wstrict-prototypes -DVARIANT_release -DCPU_MK64FN1M0VMD12 -DCPU_MK64FN1M0VMD12=1 src/main/doser.c -o release/obj/src/main/doser.o That is a good deal more than just $(CC) $(CFLAGS) -c $< -o $@ It's got include file directories that are calculated automatically, flags and warnings that vary according to the directory of the source code, separate trees for the source code, the object code, listing files and (separately generated) dependency files. Relying on the implicit rules would be a tiny saving, if anything, in my Makefiles. > Even if the whole builtin implicit rule (%.o: %.c or whatever it is) > doesn't apply, I think it probably simplifies your Makefile if you > write your own implicit rules. Untested example: > > obj-arm/%.o: %.c > $(CC) ... etc > > test/%.o: test/%.c > $(CC) ... etc Those are not implicit rules - they are /explicit/. And yes, of course I use these - the great majority of the rules run are generated from such patterns. I rarely list commands for individual files - my Makefiles don't even contain lists of the files in use (they are build from all the .c, .cpp and .h files in the source directory tree). > > In most of my Makefiles > - the link step links a main.o and a libfoo.a > - the archiver creates libfoo.a from a bunch of object files > ... and I never need to mention the source files themselves. (Almost > never. Sometimes I do anyway, when a specific file needs a different > compiler flag.) > I don't usually have any need of making a library file, but other than that my process is similar.
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2015-10-29 19:54 +0000 |
| Message-ID | <slrnn34ubu.5q5.grahn+nntp@frailea.sa.invalid> |
| In reply to | #74105 |
On Wed, 2015-10-28, David Brown wrote: > On 28/10/15 16:19, Jorgen Grahn wrote: ... >> Even if the whole builtin implicit rule (%.o: %.c or whatever it is) >> doesn't apply, I think it probably simplifies your Makefile if you >> write your own implicit rules. Untested example: >> >> obj-arm/%.o: %.c >> $(CC) ... etc >> >> test/%.o: test/%.c >> $(CC) ... etc > > Those are not implicit rules - they are /explicit/. And yes, of course > I use these - the great majority of the rules run are generated from > such patterns. GNU Make seems to call them "implicit rules", but at the same time calls them "pattern rules". The builtin ones are called "predefined implicit rules". It's pretty confusing, and I was not sure I had it right. It doesn't help that they also have "Old-Fashioned Suffix Rules" ... Anyway, it seems that we agree, beyond the terminology confusion! /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-10-30 08:44 +0100 |
| Message-ID | <n0v6vs$pk8$1@dont-email.me> |
| In reply to | #74200 |
On 29/10/15 20:54, Jorgen Grahn wrote: > On Wed, 2015-10-28, David Brown wrote: >> On 28/10/15 16:19, Jorgen Grahn wrote: > ... >>> Even if the whole builtin implicit rule (%.o: %.c or whatever it is) >>> doesn't apply, I think it probably simplifies your Makefile if you >>> write your own implicit rules. Untested example: >>> >>> obj-arm/%.o: %.c >>> $(CC) ... etc >>> >>> test/%.o: test/%.c >>> $(CC) ... etc >> >> Those are not implicit rules - they are /explicit/. And yes, of course >> I use these - the great majority of the rules run are generated from >> such patterns. > > GNU Make seems to call them "implicit rules", but at the same time > calls them "pattern rules". The builtin ones are called "predefined > implicit rules". It's pretty confusing, and I was not sure I had it > right. It doesn't help that they also have "Old-Fashioned Suffix > Rules" ... > > Anyway, it seems that we agree, beyond the terminology confusion! > I've just had another look - the GNU make manual is inconsistent, so we are both right! Let's call them "explicit implicit rules" :-) Whatever they are, they are essential to writing flexible makefiles, and I expect we both use them in approximately the same way.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-10-30 13:44 -0400 |
| Message-ID | <n10a5j$1vr$1@dont-email.me> |
| In reply to | #74234 |
On 10/30/2015 03:44 AM, David Brown wrote: > On 29/10/15 20:54, Jorgen Grahn wrote: >> On Wed, 2015-10-28, David Brown wrote: >>> On 28/10/15 16:19, Jorgen Grahn wrote: >> ... >>>> Even if the whole builtin implicit rule (%.o: %.c or whatever it is) >>>> doesn't apply, I think it probably simplifies your Makefile if you >>>> write your own implicit rules. Untested example: >>>> >>>> obj-arm/%.o: %.c >>>> $(CC) ... etc >>>> >>>> test/%.o: test/%.c >>>> $(CC) ... etc >>> >>> Those are not implicit rules - they are /explicit/. And yes, of course >>> I use these - the great majority of the rules run are generated from >>> such patterns. >> >> GNU Make seems to call them "implicit rules", but at the same time >> calls them "pattern rules". The builtin ones are called "predefined >> implicit rules". It's pretty confusing, and I was not sure I had it >> right. It doesn't help that they also have "Old-Fashioned Suffix >> Rules" ... >> >> Anyway, it seems that we agree, beyond the terminology confusion! >> > > I've just had another look - the GNU make manual is inconsistent, so we > are both right! Let's call them "explicit implicit rules" :-) > > Whatever they are, they are essential to writing flexible makefiles, and > I expect we both use them in approximately the same way. On my system, info make says the following: > Makefiles contain five kinds of things: "explicit rules", "implicit > rules", "variable definitions", "directives", and "comments". Rules, > variables, and directives are described at length in later chapters. > > * An "explicit rule" says when and how to remake one or more files, > called the rule's "targets". It lists the other files that the > targets depend on, called the "prerequisites" of the target, and > may also give commands to use to create or update the targets. > *Note Writing Rules: Rules. For example: MOD_PR03: MOD_PR03.o input.o output.o processing.o is the first line of an explicit rule. > * An "implicit rule" says when and how to remake a class of files > based on their names. It describes how a target may depend on a > file with a name similar to the target and gives commands to > create or update such a target. *Note Using Implicit Rules: > Implicit Rules. That covers every type of rule that you two have been discussing, including pattern rules and "old-fashioned" suffix rules. obj-arm/%.o: %.c The distinction seems pretty clear to me. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | guinness.tony@gmail.com |
|---|---|
| Date | 2015-10-28 04:19 -0700 |
| Message-ID | <06725d20-4392-49d3-a653-7e86178c8ab2@googlegroups.com> |
| In reply to | #74004 |
On Tuesday, 27 October 2015 20:08:51 UTC, Jorgen Grahn wrote: <snip> > >> CFLAGS=-W -Wall -pedantic -std=c99 > >> foo: foo.o > >> $(CC) $(CFLAGS) -o $@ $^ > >> > >> That should be all needed for a one-file program. > >> > > > > (foo.o should be foo.c) > > No, that was intentional. The "foo: foo.o" above just does the > linking, and there's an implicit rule (or whatever the term for it is) > which provides "foo.o: foo.c". With GNU Make at least. <snip> You don't even need to provide the (linking) action line - there is an implicit rule for that, too. This is the bare minimum Makefile that I use in these circumstances: -------------------- CFLAGS += -std=c99 -pedantic -Wall -Wextra foo: foo.o --------------------
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-10-28 12:50 +0100 |
| Message-ID | <n0qcli$6tt$1@dont-email.me> |
| In reply to | #74063 |
On 28/10/15 12:19, guinness.tony@gmail.com wrote: > On Tuesday, 27 October 2015 20:08:51 UTC, Jorgen Grahn wrote: > > <snip> > >>>> CFLAGS=-W -Wall -pedantic -std=c99 >>>> foo: foo.o >>>> $(CC) $(CFLAGS) -o $@ $^ >>>> >>>> That should be all needed for a one-file program. >>>> >>> >>> (foo.o should be foo.c) >> >> No, that was intentional. The "foo: foo.o" above just does the >> linking, and there's an implicit rule (or whatever the term for it is) >> which provides "foo.o: foo.c". With GNU Make at least. > > <snip> > > You don't even need to provide the (linking) action line - > there is an implicit rule for that, too. This is the > bare minimum Makefile that I use in these circumstances: > > -------------------- > CFLAGS += -std=c99 -pedantic -Wall -Wextra > > foo: foo.o > -------------------- > That may work, but it doesn't make sense. You are writing a source code file "foo.c", and you want the compiler to generate a program "foo" from it. You want "make" to do whatever is necessary to re-generate the binary "foo" whenever you change the source code "foo.c". So in your Makefile, write foo: foo.c This results (on my system) in "make" issuing a single command: cc -std=c99 -pedantic -Wall -Wextra foo.c -o foo By writing "foo: foo.o", you are telling make that the output file which you are interested in is dependent on an intermediary file that it first has to figure out how to build, and figure out about the dependencies. It results (on my system) in the commands: cc -std=c99 -pedantic -Wall -Wextra -c -o foo.o foo.c cc foo.o -o foo This is more work for both make and the compiler and anyone trying to figure out what is happening with more complex makefiles, makes things difficult if you want options passed to both the compile phase and the link phase (such as "-flto" or "-g"), and clutters your directory with useless .o files. Write your Makefile in a clear way. If you want to turn a .c file into a program file, write that. Don't start including other intermediary files unless you actually want them.
[toc] | [prev] | [next] | [standalone]
| From | guinness.tony@gmail.com |
|---|---|
| Date | 2015-10-28 08:19 -0700 |
| Message-ID | <978f92da-ddae-4951-93c1-d1947ded9d3f@googlegroups.com> |
| In reply to | #74068 |
On Wednesday, 28 October 2015 11:50:24 UTC, David Brown wrote: > On 28/10/15 12:19, guinness.tony@gmail.com wrote: > > On Tuesday, 27 October 2015 20:08:51 UTC, Jorgen Grahn wrote: > > > > <snip> > > > >>>> CFLAGS=-W -Wall -pedantic -std=c99 > >>>> foo: foo.o > >>>> $(CC) $(CFLAGS) -o $@ $^ > >>>> > >>>> That should be all needed for a one-file program. > >>>> > >>> > >>> (foo.o should be foo.c) > >> > >> No, that was intentional. The "foo: foo.o" above just does the > >> linking, and there's an implicit rule (or whatever the term for it is) > >> which provides "foo.o: foo.c". With GNU Make at least. > > > > <snip> > > > > You don't even need to provide the (linking) action line - > > there is an implicit rule for that, too. This is the > > bare minimum Makefile that I use in these circumstances: > > > > -------------------- > > CFLAGS += -std=c99 -pedantic -Wall -Wextra > > > > foo: foo.o > > -------------------- > > > > That may work, but it doesn't make sense. You are writing a source code > file "foo.c", and you want the compiler to generate a program "foo" from > it. You want "make" to do whatever is necessary to re-generate the > binary "foo" whenever you change the source code "foo.c". > > So in your Makefile, write > > foo: foo.c > > This results (on my system) in "make" issuing a single command: > > cc -std=c99 -pedantic -Wall -Wextra foo.c -o foo > > > By writing "foo: foo.o", you are telling make that the output file which > you are interested in is dependent on an intermediary file that it first > has to figure out how to build, and figure out about the dependencies. > It results (on my system) in the commands: > > cc -std=c99 -pedantic -Wall -Wextra -c -o foo.o foo.c > cc foo.o -o foo Exactly - it figures out the dependencies. It scales well to many source files, only a few of which have changed, rather than recompiling every source file every time. It also works with sources of mixed language (e.g. C++), where a different compiler (g++, for instance) is invoked to create the .o file. > This is more work for both make and the compiler and anyone trying to > figure out what is happening with more complex makefiles, makes things > difficult if you want options passed to both the compile phase and the > link phase (such as "-flto" or "-g"), and clutters your directory with > useless .o files. > > > Write your Makefile in a clear way. If you want to turn a .c file into > a program file, write that. Don't start including other intermediary > files unless you actually want them. Admittedly, in general, I do want them (so that dependencies are checked), because I'm usually working with a large codebase. But I do take your point about the specific case being discussed here. (Old habits die hard!)
[toc] | [prev] | [next] | [standalone]
| From | guinness.tony@gmail.com |
|---|---|
| Date | 2015-10-28 10:21 -0700 |
| Message-ID | <c9137430-bd9b-461a-b578-9e47c297f20a@googlegroups.com> |
| In reply to | #74085 |
On Wednesday, 28 October 2015 15:19:48 UTC, guinne...@gmail.com wrote: <snip> > Exactly - it figures out the dependencies. It scales well to many source files, only a few of which have changed, rather than recompiling every source file every time. It also works with sources of mixed language (e.g. C++), <snip> I shall slap my own wrist as punishment for not wrapping my lines!
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-10-28 22:34 +0100 |
| Message-ID | <n0retm$kj5$1@dont-email.me> |
| In reply to | #74085 |
On 28/10/15 16:19, guinness.tony@gmail.com wrote: > On Wednesday, 28 October 2015 11:50:24 UTC, David Brown wrote: >> On 28/10/15 12:19, guinness.tony@gmail.com wrote: >>> On Tuesday, 27 October 2015 20:08:51 UTC, Jorgen Grahn wrote: >>> >>> <snip> >>> >>>>>> CFLAGS=-W -Wall -pedantic -std=c99 >>>>>> foo: foo.o >>>>>> $(CC) $(CFLAGS) -o $@ $^ >>>>>> >>>>>> That should be all needed for a one-file program. >>>>>> >>>>> >>>>> (foo.o should be foo.c) >>>> >>>> No, that was intentional. The "foo: foo.o" above just does the >>>> linking, and there's an implicit rule (or whatever the term for it is) >>>> which provides "foo.o: foo.c". With GNU Make at least. >>> >>> <snip> >>> >>> You don't even need to provide the (linking) action line - >>> there is an implicit rule for that, too. This is the >>> bare minimum Makefile that I use in these circumstances: >>> >>> -------------------- >>> CFLAGS += -std=c99 -pedantic -Wall -Wextra >>> >>> foo: foo.o >>> -------------------- >>> >> >> That may work, but it doesn't make sense. You are writing a source code >> file "foo.c", and you want the compiler to generate a program "foo" from >> it. You want "make" to do whatever is necessary to re-generate the >> binary "foo" whenever you change the source code "foo.c". >> >> So in your Makefile, write >> >> foo: foo.c >> >> This results (on my system) in "make" issuing a single command: >> >> cc -std=c99 -pedantic -Wall -Wextra foo.c -o foo >> >> >> By writing "foo: foo.o", you are telling make that the output file which >> you are interested in is dependent on an intermediary file that it first >> has to figure out how to build, and figure out about the dependencies. >> It results (on my system) in the commands: >> >> cc -std=c99 -pedantic -Wall -Wextra -c -o foo.o foo.c >> cc foo.o -o foo > > Exactly - it figures out the dependencies. It scales well to many source files, only a few of which have changed, rather than recompiling every source file every time. It also works with sources of mixed language (e.g. C++), > where a different compiler (g++, for instance) is invoked to create the > .o file. It does not figure out /all/ the dependencies - you have told Make that foo depends on foo.o, and Make figures out that foo.o depends on foo.<something>, and tries foo.c, foo.C, foo.cpp, etc, using which ever one it finds (hopefully it won't find more than one possibility). So using "foo: foo.o" does not scale better nor figure out anything better than using "foo: foo.c". It works in simple cases, but unless I am missing something major here, it is a poorer choice in many ways. If you /want/ the .o files - and there are good reasons for doing so - then ask for them: foo: foo.o foo.o: foo.c (or use "%.o: %.c" for a pattern matching rule.) > >> This is more work for both make and the compiler and anyone trying to >> figure out what is happening with more complex makefiles, makes things >> difficult if you want options passed to both the compile phase and the >> link phase (such as "-flto" or "-g"), and clutters your directory with >> useless .o files. >> >> >> Write your Makefile in a clear way. If you want to turn a .c file into >> a program file, write that. Don't start including other intermediary >> files unless you actually want them. > > Admittedly, in general, I do want them (so that dependencies are checked), > because I'm usually working with a large codebase. Keeping the .o files does not add any dependency checking. It improves scalability because you only re-compile the files you need to - assuming you have specified other dependencies as well. So for projects of more than a few files, you probably want to generate and keep the .o files (but not mixed in the same directory as the source files, if you can avoid it). > > But I do take your point about the specific case being discussed here. > (Old habits die hard!) >
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-11-10 15:50 +0000 |
| Message-ID | <56421013.3416078@news.xs4all.nl> |
| In reply to | #74107 |
David Brown <david.brown@hesbynett.no> wrote: > On 28/10/15 16:19, guinness.tony@gmail.com wrote: > > Exactly - it figures out the dependencies. It scales well to many source files, only a few of which have changed, rather than recompiling every source file every time. It also works with sources of mixed language (e.g. C++), > > where a different compiler (g++, for instance) is invoked to create the > > .o file. > > It does not figure out /all/ the dependencies - you have told Make that > foo depends on foo.o, and Make figures out that foo.o depends on > foo.<something>, and tries foo.c, foo.C, foo.cpp, etc, using which ever > one it finds (hopefully it won't find more than one possibility). > > So using "foo: foo.o" does not scale better nor figure out anything > better than using "foo: foo.c". It works in simple cases, but unless I > am missing something major here, it is a poorer choice in many ways. And in any case, in almost all my projects many units depend on the headers from at least one other - sometimes mutually. This may not _yet_ be the case here, but soon enough any programmer is going to have to learn to write: calendar.o: calendar.c calendar.h people.h or even: anniversary.o: anniversary.c anniversary.h people.h people.o: people.c people.h anniversary.h (Sorry, I used the anathema space. Tabs don't scale well to Usenet - or real world proper editors!) The mutual case can, of course, be resolved by separating out the mutually used data types into a third header; but this only solves the circularity, not the need for headers in general - nor should it. Richard
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-10-27 14:13 +0000 |
| Message-ID | <87mvv4iemo.fsf@bsb.me.uk> |
| In reply to | #73954 |
Jorgen Grahn <grahn+nntp@snipabacken.se> writes: > On Mon, 2015-10-26, Richard Heathfield wrote: <snip> >> Do you seriously think that's a problem? You're a C programmer, right? >> How hard could it be to write a C program to generate the makefile for >> you? Mine is about 130 lines of bog-standard ordinary C. > > Why would you want to do that when you can just write the Makefile > manually? > > CFLAGS=-W -Wall -pedantic -std=c99 (-W means -Wall) > foo: foo.o > $(CC) $(CFLAGS) -o $@ $^ > > That should be all needed for a one-file program. For many student exercises you don't need the "magic" bits. You can just provide a on-line makefile with CFLAGS=-std=c99 -pedentic -Wall -Wextra and the students type make myprog The default rules (usually) do what's wanted. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-10-27 14:15 +0000 |
| Message-ID | <n0o0qd$lt$1@dont-email.me> |
| In reply to | #73960 |
On 27/10/15 14:13, Ben Bacarisse wrote: <snip> > For many student exercises you don't need the "magic" bits. You can > just provide a on-line makefile with > > CFLAGS=-std=c99 -pedentic -Wall -Wextra I hate to be pedentic, but... :-) -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-27 08:59 -0700 |
| Message-ID | <ln1tcge1zo.fsf@kst-u.example.com> |
| In reply to | #73960 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Jorgen Grahn <grahn+nntp@snipabacken.se> writes:
[...]
>> Why would you want to do that when you can just write the Makefile
>> manually?
>>
>> CFLAGS=-W -Wall -pedantic -std=c99
>
> (-W means -Wall)
No, -W means -Wextra.
'-Wextra'
This enables some extra warning flags that are not enabled by
'-Wall'. (This option used to be called '-W'. The older name
is still supported, but the newer name is more descriptive.)
(To be clear this refers to gcc, and probably to other compilers that
are compatible with it. There are of course other compilers with other
options.)
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-10-27 21:34 +0000 |
| Message-ID | <87611shu7m.fsf@bsb.me.uk> |
| In reply to | #73969 |
Keith Thompson <kst-u@mib.org> writes: > Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >> Jorgen Grahn <grahn+nntp@snipabacken.se> writes: <snip> >>> CFLAGS=-W -Wall -pedantic -std=c99 >> >> (-W means -Wall) > > No, -W means -Wextra. Ah, yes indeed. Thanks. (Don't know where that false memory came from.) ,snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-10-27 12:09 -0400 |
| Message-ID | <n0o7f3$pse$2@dont-email.me> |
| In reply to | #73954 |
On 10/27/2015 09:36 AM, Jorgen Grahn wrote: > On Mon, 2015-10-26, Richard Heathfield wrote: >> On 26/10/15 16:26, Bartc wrote: >>> On 26/10/2015 15:21, Richard Heathfield wrote: ... >>>> -W -Wall -pedantic -Wformat-nonliteral -Wcast-align -Wpointer-arith >>>> -Wbad-function-cast -Wmissing-prototypes -Wstrict-prototypes >>>> -Wno-missing-field-initializers -Wmissing-declarations -Winline -Wundef >>>> -Wnested-externs -Wcast-qual -Wshadow -Wconversion -Wwrite-strings ... >>> Next problem is how to arrange for that lot to be given to the compiler >>> automatically, without having to type them in every time. >> >> Do you seriously think that's a problem? You're a C programmer, right? >> How hard could it be to write a C program to generate the makefile for >> you? Mine is about 130 lines of bog-standard ordinary C. > > Why would you want to do that when you can just write the Makefile > manually? > > CFLAGS=-W -Wall -pedantic -std=c99 > foo: foo.o > $(CC) $(CFLAGS) -o $@ $^ Why even write a make file? The default rules for Unix make pick up the CFLAGS environment variable, and use it in an appropriate fashion. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2015-10-27 20:03 +0000 |
| Message-ID | <slrnn2vm3v.5q5.grahn+nntp@frailea.sa.invalid> |
| In reply to | #73973 |
On Tue, 2015-10-27, James Kuyper wrote: ... > Why even write a make file? The default rules for Unix make pick up the > CFLAGS environment variable, and use it in an appropriate fashion. To have them recorded together with the source code. I hate receiving source code from someone, and having to figure out myself how to build it. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-10-27 19:36 -0400 |
| Message-ID | <n0p1m2$9fo$1@dont-email.me> |
| In reply to | #74003 |
On 10/27/2015 04:03 PM, Jorgen Grahn wrote: > On Tue, 2015-10-27, James Kuyper wrote: > ... >> Why even write a make file? The default rules for Unix make pick up the >> CFLAGS environment variable, and use it in an appropriate fashion. > > To have them recorded together with the source code. I hate receiving > source code from someone, and having to figure out myself how to build > it. I only suggested that because this particular program has a vey simple structure. If you receive source code that relies entirely upon make's default rules, among other things that implies that the program consists entirely of one module, so it can't be a very complicated build. The delivery should identify the values that you should set the relevant environment variables to - and that's essentially all you need to know in order to build it. For programs of any reasonable size, knowing and making good use of make's default rules can greatly simplify your make file, but does not eliminate the need for one. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-10-28 09:06 +0100 |
| Message-ID | <n0pvi7$q78$1@dont-email.me> |
| In reply to | #74028 |
On 28/10/15 00:36, James Kuyper wrote: > On 10/27/2015 04:03 PM, Jorgen Grahn wrote: >> On Tue, 2015-10-27, James Kuyper wrote: >> ... >>> Why even write a make file? The default rules for Unix make pick up the >>> CFLAGS environment variable, and use it in an appropriate fashion. >> >> To have them recorded together with the source code. I hate receiving >> source code from someone, and having to figure out myself how to build >> it. > > I only suggested that because this particular program has a vey simple > structure. If you receive source code that relies entirely upon make's > default rules, among other things that implies that the program consists > entirely of one module, so it can't be a very complicated build. The > delivery should identify the values that you should set the relevant > environment variables to - and that's essentially all you need to know > in order to build it. > > For programs of any reasonable size, knowing and making good use of > make's default rules can greatly simplify your make file, but does not > eliminate the need for one. > For code which is designed to work across a range of systems, compilers and options, then using the default rules makes sense - it keeps things simple, and lets the user easily make his own choices of flags, compilers, etc. But for code with specific requirements (say, -std=gnu11), it is a pain if these things are /not/ in the Makefile. It is always annoying when something builds fine on one system, but not on another - and the required flags should not be hidden in somebody's CFLAGS settings in their .bashrc. Of course, requirements can be mentioned in readmes or other documentation, but when those requirements can be expressed clearly in a Makefile, that's where they should go for everybody's convenience.
[toc] | [prev] | [next] | [standalone]
Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →
Back to top | Article view | comp.lang.c
csiph-web