Re: [dev] Reasonable Makefiles
> So the Makefile has this: > > all: autoconfig $(BIN) > > autoconfig: > sh config.uname >> config.mk > touch $@ > > and config.uname is a shell script along these lines: > > #!/bin/sh > > os=`uname` > > case $os in > Darwin ) > echo 'Configuring for Darwin' >&2 > echo '# Extra configuration for Darwin (from config.uname)' > echo 'EXTRA_CPPFLAGS = -I/opt/local/include' > ;; > esac > It is similar to the configure of utmp, and usually it is the only thing you need. Regards, -- Roberto E. Vargas Caballero
Re: [dev] Reasonable Makefiles
Quoth Nick: > Basically because I'm replacing a autotools horrorshow with > plain make, but am not sure what the nicest way of allowing compile- > time feature disabling is. Can 'ifdef' be relied upon, and does it > tend to produce unreadable and buggy makefiles in anyone's > experience? Are there other options, beyond asking people to comment > out certain lines in a config.mk, to e.g. disable some LDFLAGS? So I changed my goal slightly to just do basic build variable adjustments based on the system. I ended up creating a bourne script called config.uname, which sets a few sensible defaults for weird systems (like OSX & solaris), and appends them to the config.mk, on first compilation. So that they can still be changed by editing config.mk if you want, and they're not hidden away in some 'ifeq' using included Makefile. So the Makefile has this: all: autoconfig $(BIN) autoconfig: sh config.uname >> config.mk touch $@ and config.uname is a shell script along these lines: #!/bin/sh os=`uname` case $os in Darwin ) echo 'Configuring for Darwin' >&2 echo '# Extra configuration for Darwin (from config.uname)' echo 'EXTRA_CPPFLAGS = -I/opt/local/include' ;; esac It seems to me like a pretty reasonable and usable way of doing some basic autoconfiguration for different systems. Comments, anyone? Nick
Re: [dev] Reasonable Makefiles
Nick said: > Interesting. How do you handle things like ldflags and cflags for > specific libraries? Are they just all listed in the central > config.mk, with more lines added when an application is added that > needs them? You might have a look at BSD's ports infrastructure: there is some single location of settings somewhere in ports infrastructure itself, a user-editable configuration file (I expect Anselm would replace those with one config.mk) and individual ports that need some specific flags override the config values in their makefiles. -- Dmitrij D. Czarkoff
Re: [dev] Reasonable Makefiles
On Tue, Feb 18, 2014 at 03:21:53PM +0100, Anselm R Garbe wrote: > Exactly. I would even go a bit further than that. When designing my > stali Makefile's, I only have a single config.mk in a central place, > but many Makefiles for each dependency that include the central > config.mk Interesting. How do you handle things like ldflags and cflags for specific libraries? Are they just all listed in the central config.mk, with more lines added when an application is added that needs them? That sounds reasonable to me, though it could look a bit unwieldy to a newcomer as presumably there would be lots of lines for specific libraries, most of which would probably not need to be touched.
Re: [dev] Reasonable Makefiles
On 11 February 2014 14:32, Kurt Van Dijck wrote: > On Tue, Feb 11, 2014 at 11:41:43AM +0100, FRIGN wrote: >> Regarding the config.mk, I don't see the benefit, either. > > The major benefit I see is: > config.mk is build/host/target specific, Makefile is not. > Makefile goes into versioning, config.mk does not. > Combinining those complicates life. Exactly. I would even go a bit further than that. When designing my stali Makefile's, I only have a single config.mk in a central place, but many Makefiles for each dependency that include the central config.mk So in theory one config.mk per system should be enough. -Anselm
Re: *** GMX Spamverdacht *** [dev] Reasonable Makefiles
On Tue, Feb 11, 2014 at 07:16:35PM +0100, Markus Wichmann wrote: > On Tue, Feb 11, 2014 at 12:19:59PM +, Nick wrote: > > I was reading the opengroup specifications for make(1) recently[0], > > and found that even our standard makefile practise of using 'include' > > for config variables is nonstandard, as far as they're concerned. > > Needless to say I think 'include' is a perfectly reasonable feature > > to use, and it evidently works everywhere that people care about. > > > > But it got me thinking about what other features of make are worth > > using. Basically because I'm replacing a autotools horrorshow with > > plain make, but am not sure what the nicest way of allowing compile- > > time feature disabling is. Can 'ifdef' be relied upon, and does it > > tend to produce unreadable and buggy makefiles in anyone's > > experience? Are there other options, beyond asking people to comment > > out certain lines in a config.mk, to e.g. disable some LDFLAGS? > > > > If you want a nice looking user interface for choices, have a look at > kconf. Otherwise just assume that people know to look for the correct > variable to change what they need. Using autoconf just to spare people > the pain of opening an editor is really not worth it. kconf? really? > By the way, I usually write my Makefiles for GNU make. Its > implementation may be bad, but its ideas are also used in mk. Good luck. > Why did make become the horrible cancer that it is today? Because > developers thought it inadequate in some respects and made > vendor-specific changes. Who's to say that won't happen for mk? I mean, > assuming it ever gets sufficient exposure (sorry guys, but technological > superiority doesn't guarentee market share, which is the primary reason > for autohell, cmake, and qmake), someone will want to change > something about it. Things will grow on it. mk will become just as > bloated as make, come 20 years or so. Because people like you choose to be insane. > Why? If Linux wasn't as configurable as it is, it would be completely > unusable, or would you rather compiler _all_ the drivers all the time? > Same for other software. Yes.
Re: *** GMX Spamverdacht *** [dev] Reasonable Makefiles
On Tue, Feb 11, 2014 at 12:19:59PM +, Nick wrote: > I was reading the opengroup specifications for make(1) recently[0], > and found that even our standard makefile practise of using 'include' > for config variables is nonstandard, as far as they're concerned. > Needless to say I think 'include' is a perfectly reasonable feature > to use, and it evidently works everywhere that people care about. > > But it got me thinking about what other features of make are worth > using. Basically because I'm replacing a autotools horrorshow with > plain make, but am not sure what the nicest way of allowing compile- > time feature disabling is. Can 'ifdef' be relied upon, and does it > tend to produce unreadable and buggy makefiles in anyone's > experience? Are there other options, beyond asking people to comment > out certain lines in a config.mk, to e.g. disable some LDFLAGS? > If you want a nice looking user interface for choices, have a look at kconf. Otherwise just assume that people know to look for the correct variable to change what they need. Using autoconf just to spare people the pain of opening an editor is really not worth it. By the way, I usually write my Makefiles for GNU make. Its implementation may be bad, but its ideas are also used in mk. A typical Makefile of mine looks like this: SRC:=$(wildcard *.c) OBJ:=$(SRC:.c=.o) output: $(OBJ) $(CC) $(LDFLAGS) -o $@ $^ $(LIBS) ifneq ($(MAKECMDGOALS),clean) include dep endif dep: $(SRC) $(CC) $(CFLAGS) -MM -o $@ $^ %.o: %.c $(CC) $(CFLAGS) -c -o $@ $< .PHONY: clean clean: rm -f dep core output $(OBJ) That's it. Works for me. > I know switching to mk would solve all of my problems and give me > something standard and portable, but it would also be a dependency > which isn't as widely installed as make, which I'm not overly keen on. > Why did make become the horrible cancer that it is today? Because developers thought it inadequate in some respects and made vendor-specific changes. Who's to say that won't happen for mk? I mean, assuming it ever gets sufficient exposure (sorry guys, but technological superiority doesn't guarentee market share, which is the primary reason for autohell, cmake, and qmake), someone will want to change something about it. Things will grow on it. mk will become just as bloated as make, come 20 years or so. > And also I generally agree that compile-time options are a bad plan, > but one fight at a time, eh? > Why? If Linux wasn't as configurable as it is, it would be completely unusable, or would you rather compiler _all_ the drivers all the time? Same for other software. > Nick > Ciao, Markus
Re: [dev] Reasonable Makefiles
> The disadvantage of that is that having files called Makefile and > makefile in the same directory, users may well look for the former to > make changes, leading to confusion. I certainly didn't know that Yes, it is true, you have to be carefull with this point, but usually is not a problem. > Also, having created the makefile, does the Makefile invoke make > again automatically, or does the user have to re-enter their user has to write something like: make dep and then the new makefile is created. Next time user executes 'make' then makefile will be used instead of Makefile. I have these rules: dep: (cat Makefile ; \ for i in $(OBJS:.o=.c) ;\ do \ $(CC) $(CPPFLAGS) $(CFLAGS) -MM $$i ; \ done) > makefile disctclean: clean rm -f makefile You can do something similar using only a Makefile and these rules: dep: (echo '#Cut here' for i in $(OBJS:.o=.c) ;\ do \ $(CC) $(CPPFLAGS) $(CFLAGS) -MM $$i ;\ done) >> Makefile ;\ distclean: clean printf "/^#Cut here/,$d\nw\nq\n" | ed -s Makefile but then you will have problems with your control version system. You can avoid the confusion of Makefile and makefile if you use other names: for example gen.mk (and it generates Makefile, so the user knows that he is working with a generated Makefile). I usually don't like this way because the user should read the documentation and see the Makefile/makefile issue. Regards, -- Roberto E. Vargas Caballero
Re: [dev] Reasonable Makefiles
On Tue, Feb 11, 2014 at 03:41:43PM +0100, Roberto E. Vargas Caballero wrote: > On Tue, Feb 11, 2014 at 02:39:43PM +0100, pmarin wrote: > > You don't need to use the include statement. > > cat config.mk Makefile | make -f - > > I usually use a rule in Makefile that, using cat in a similar way of > you, generates a file with the name makefile (it usually generates > the inclussion dependences and other things). The disadvantage of that is that having files called Makefile and makefile in the same directory, users may well look for the former to make changes, leading to confusion. I certainly didn't know that make looks for for 'makefile' before 'Makefile' until looking it up just now. Also, having created the makefile, does the Makefile invoke make again automatically, or does the user have to re-enter their command? If I type 'make foo' for the first time, what happens? Presumably the target 'foo' isn't made...
Re: [dev] Reasonable Makefiles
On Tue, Feb 11, 2014 at 01:28:42PM +, sin wrote: > It also makes it easy to have a configure script like as shown below: > > #!/bin/sh > > case `uname` in > OpenBSD) > ln config.bsd config.mk > ;; > *) > ln config.posix config.mk > ;; > esac Aha! Now there's a good idea. I hadn't seriously considered using a script (because of the bad feelings that come with running most ./configure scripts), but something like that sounds ideal for my purposes. Thanks sin!
Re: [dev] Reasonable Makefiles
On Tue, Feb 11, 2014 at 02:39:43PM +0100, pmarin wrote: > You don't need to use the include statement. > cat config.mk Makefile | make -f - I usually use a rule in Makefile that, using cat in a similar way of you, generates a file with the name makefile (it usually generates the inclussion dependences and other things). Regards, -- Roberto E. Vargas Caballero
Re: [dev] Reasonable Makefiles
On Tue, 11 Feb 2014 14:32:58 +0100 Kurt Van Dijck wrote: > I would using 2 files hardly call 'decentralized'. Things can become worse > than that :-) Haha, yeah, that's definitely true! Thanks for the heads up, these are definitely good reasons to go for the separated approach. Cheers FRIGN -- FRIGN
Re: [dev] Reasonable Makefiles
You don't need to use the include statement. cat config.mk Makefile | make -f - pmarin. On Tue, Feb 11, 2014 at 1:19 PM, Nick wrote: > I was reading the opengroup specifications for make(1) recently[0], > and found that even our standard makefile practise of using 'include' > for config variables is nonstandard, as far as they're concerned. > Needless to say I think 'include' is a perfectly reasonable feature > to use, and it evidently works everywhere that people care about. > > But it got me thinking about what other features of make are worth > using. Basically because I'm replacing a autotools horrorshow with > plain make, but am not sure what the nicest way of allowing compile- > time feature disabling is. Can 'ifdef' be relied upon, and does it > tend to produce unreadable and buggy makefiles in anyone's > experience? Are there other options, beyond asking people to comment > out certain lines in a config.mk, to e.g. disable some LDFLAGS? > > I know switching to mk would solve all of my problems and give me > something standard and portable, but it would also be a dependency > which isn't as widely installed as make, which I'm not overly keen on. > > And also I generally agree that compile-time options are a bad plan, > but one fight at a time, eh? > > Nick > > 0. http://pubs.opengroup.org/onlinepubs/009695399/utilities/make.html >
Re: [dev] Reasonable Makefiles
On Tue, Feb 11, 2014 at 11:41:43AM +0100, FRIGN wrote: > On Tue, 11 Feb 2014 13:28:25 +0100 > Markus Teich wrote: > > > Heyho, > > > > Regarding the include config.mk used in various suckless projects: What is > > the > > benefit? If a user needs to adapt it to his system, he effectively has to > > edit a > > file. Would there be a problem if this file would be the Makefile instead > > of the > > config.mk file? > > Regarding the config.mk, I don't see the benefit, either. The major benefit I see is: config.mk is build/host/target specific, Makefile is not. Makefile goes into versioning, config.mk does not. Combinining those complicates life. > If I didn't > know the concept how suckless-projects are organized in regard to their > makefiles, I would look at the Makefile first and probably not notice > the config.mk. Editing directly in Makefile does work, but complicates long term maintenance. Your argument does not show that using config.mk is a wrong concept, it illustrates that it's not enforced. [...] > > I myself prefer a centralized make-system over a decentralized one with > includes, but I'm sure there are people around here who can give good > reasons for decentralizing this. I would using 2 files hardly call 'decentralized'. Things can become worse than that :-) Kurt
Re: [dev] Reasonable Makefiles
On Tue, Feb 11, 2014 at 01:28:25PM +0100, Markus Teich wrote: > Nick wrote: > > I was reading the opengroup specifications for make(1) recently[0], > > and found that even our standard makefile practise of using 'include' > > for config variables is nonstandard, as far as they're concerned. > > Needless to say I think 'include' is a perfectly reasonable feature > > to use, and it evidently works everywhere that people care about. > > Heyho, > > Regarding the include config.mk used in various suckless projects: What is the > benefit? If a user needs to adapt it to his system, he effectively has to > edit a > file. Would there be a problem if this file would be the Makefile instead of > the > config.mk file? It also makes it possible to modify the Makefile at will without causing potential conflict headaches for users. Sure that's also possible with config.mk but it is much less likely that it will change. Almost no one gets Makefiles right the first time, so they are subject to change.
Re: [dev] Reasonable Makefiles
On Tue, Feb 11, 2014 at 01:28:25PM +0100, Markus Teich wrote: > Nick wrote: > > I was reading the opengroup specifications for make(1) recently[0], > > and found that even our standard makefile practise of using 'include' > > for config variables is nonstandard, as far as they're concerned. > > Needless to say I think 'include' is a perfectly reasonable feature > > to use, and it evidently works everywhere that people care about. > > Heyho, > > Regarding the include config.mk used in various suckless projects: What is the > benefit? If a user needs to adapt it to his system, he effectively has to > edit a > file. Would there be a problem if this file would be the Makefile instead of > the > config.mk file? It is clear separation between user-configured variables and generic code. It also makes it easy to have a configure script like as shown below: #!/bin/sh case `uname` in OpenBSD) ln config.bsd config.mk ;; *) ln config.posix config.mk ;; esac This was taken from utmp[1]. This doesn't duplicate the entire Makefile. [1] http://git.suckless.org/utmp cheers, sin
Re: [dev] Reasonable Makefiles
On Tue, 11 Feb 2014 13:28:25 +0100 Markus Teich wrote: > Heyho, > > Regarding the include config.mk used in various suckless projects: What is the > benefit? If a user needs to adapt it to his system, he effectively has to > edit a > file. Would there be a problem if this file would be the Makefile instead of > the > config.mk file? Regarding the config.mk, I don't see the benefit, either. If I didn't know the concept how suckless-projects are organized in regard to their makefiles, I would look at the Makefile first and probably not notice the config.mk. Regarding including in general, take projects like 9base into consideration, where each subdirectory includes standard build procedures. I myself prefer a centralized make-system over a decentralized one with includes, but I'm sure there are people around here who can give good reasons for decentralizing this. Cheers FRIGN -- FRIGN
Re: [dev] Reasonable Makefiles
On 14-02-11 13:28:25, Markus Teich wrote: Nick wrote: I was reading the opengroup specifications for make(1) recently[0], and found that even our standard makefile practise of using 'include' for config variables is nonstandard, as far as they're concerned. Needless to say I think 'include' is a perfectly reasonable feature to use, and it evidently works everywhere that people care about. Heyho, Regarding the include config.mk used in various suckless projects: What is the benefit? If a user needs to adapt it to his system, he effectively has to edit a file. Would there be a problem if this file would be the Makefile instead of the config.mk file? Regards, Markus To me this is a clean, user-facing “interface”. Yes, the user still edits a Makefile of sorts, but he gets the clear message - this is the stuff you can tune by just editing some variables, no need to investigate the actual build process if this suffices, no risk of breaking the build by messing up Makefile indents or some other weirdness etc. regards, Tom pgp7Oq_r4XaM4.pgp Description: PGP signature
Re: [dev] Reasonable Makefiles
Nick wrote: > I was reading the opengroup specifications for make(1) recently[0], > and found that even our standard makefile practise of using 'include' > for config variables is nonstandard, as far as they're concerned. > Needless to say I think 'include' is a perfectly reasonable feature > to use, and it evidently works everywhere that people care about. Heyho, Regarding the include config.mk used in various suckless projects: What is the benefit? If a user needs to adapt it to his system, he effectively has to edit a file. Would there be a problem if this file would be the Makefile instead of the config.mk file? Regards, Markus
[dev] Reasonable Makefiles
I was reading the opengroup specifications for make(1) recently[0], and found that even our standard makefile practise of using 'include' for config variables is nonstandard, as far as they're concerned. Needless to say I think 'include' is a perfectly reasonable feature to use, and it evidently works everywhere that people care about. But it got me thinking about what other features of make are worth using. Basically because I'm replacing a autotools horrorshow with plain make, but am not sure what the nicest way of allowing compile- time feature disabling is. Can 'ifdef' be relied upon, and does it tend to produce unreadable and buggy makefiles in anyone's experience? Are there other options, beyond asking people to comment out certain lines in a config.mk, to e.g. disable some LDFLAGS? I know switching to mk would solve all of my problems and give me something standard and portable, but it would also be a dependency which isn't as widely installed as make, which I'm not overly keen on. And also I generally agree that compile-time options are a bad plan, but one fight at a time, eh? Nick 0. http://pubs.opengroup.org/onlinepubs/009695399/utilities/make.html
