> 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' >&
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
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
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. Ho
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
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 nons
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'
> 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.
>
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
>
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 id
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 depende
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
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 variable
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
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.
> > Nee
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.
> > Nee
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 Make
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
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 us
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 wo
20 matches
Mail list logo
