> > I did not promote the LLVM alternatives to binutils, just noted that
> > FreeBSD (where the elftoolchain project started) seem to move towards
> > the LLVM utilities instead (so I don't know how much development there
> > is on elftoolchain).
>
> This is very bad omens for the *BSD people.
On Thu, Feb 09, 2017 at 12:42:45PM +0100, Jens Staal wrote:
> I did not promote the LLVM alternatives to binutils, just noted that
> FreeBSD (where the elftoolchain project started) seem to move towards
> the LLVM utilities instead (so I don't know how much development there
> is on elftoolchain).
On Thu, Feb 09, 2017 at 10:17:13AM +, sylvain.bertr...@gmail.com wrote:
> On Thu, Feb 09, 2017 at 09:29:08AM +0100, Jens Staal wrote:
> > On Wed, Feb 08, 2017 at 06:37:39PM -0500, stephen Turner wrote:
> > > From a user perspective it has been a treat. I had issues with the GNU
> > > M4
On Thu, Feb 09, 2017 at 09:29:08AM +0100, Jens Staal wrote:
> On Wed, Feb 08, 2017 at 06:37:39PM -0500, stephen Turner wrote:
> > From a user perspective it has been a treat. I had issues with the GNU
> > M4 compiling on a embedded musl and PCC system but this M4 compiled
> > quick and clean. The
On Wed, Feb 08, 2017 at 06:37:39PM -0500, stephen Turner wrote:
> From a user perspective it has been a treat. I had issues with the GNU
> M4 compiling on a embedded musl and PCC system but this M4 compiled
> quick and clean. The only potential downside i can think of is it may
> not be well
>From a user perspective it has been a treat. I had issues with the GNU
M4 compiling on a embedded musl and PCC system but this M4 compiled
quick and clean. The only potential downside i can think of is it may
not be well maintained. last i checked the website there were no new
releases from when
It looks pretty good, maybe we should recommend it as an
external component.
On Tue, 7 Feb 2017 09:43:42 -0500
stephen Turner wrote:
> I think this was blocked by the mailing list, sorry if
> its a duplicate. I wanted to mention that there is a m4
> converted from a
I think this was blocked by the mailing list, sorry if its a
duplicate. I wanted to mention that there is a m4 converted from a bsd
rewrite of m4 into a more Linux compatible version, he advised it had all
the popularly used features but may be missing a few of the lesser used. I
for one have
Mattias Andrée wrote:
> I'm not convinced mk(1) is less sucky
> than POSIX make(1), but it may be less
> sucky than many make(1) implementations.
There is also bmake(1)[0], a port of NetBSD's
make(1)[1]. OpenBSD has their own
make(1)[2] as well.
Cág
[0]:
On Thu, Feb 02, 2017 at 06:45:49PM +0100, Mattias Andrée wrote:
> I'm work on implementing make(1)
In theory, linux kbuild should be a good reference for the minimum set of
makefile extensions to code. Well, in theory, the guys paid full-time at the
linux fondation to work on kbuild, should have
On Thu, 02 Feb 2017 17:59:14 -0600
Joshua Haase wrote:
> Mattias Andrée writes:
> > Also, I think mk(1) uses rc(1), right?
>
> On plan9port it uses the shell defined on the environment.
That's not precisely portable.
>
> I think `mk` is way more
On Thu, Feb 2, 2017, at 18:44, Mattias Andrée wrote:
> Also, I think mk(1) uses rc(1), right?
The variable MKSHELL contains the shell command line mk uses
to run recipes. If the first word of the command ends in rc
or rcsh, mk uses rc(1)'s quoting rules; otherwise
Mattias Andrée writes:
> Also, I think mk(1) uses rc(1), right?
On plan9port it uses the shell defined on the environment.
I think `mk` is way more suckless.
On Thu, 02 Feb 2017 17:08:17 -0600
Joshua Haase wrote:
> Mattias Andrée writes:
>
> > Greetings!
> >
> > I'm work on implementing make(1), and I have two
> > questions for you:
>
> Why make and not mk?
Also, I think mk(1) uses rc(1), right?
On Thu, 02 Feb 2017 17:08:17 -0600
Joshua Haase wrote:
> Mattias Andrée writes:
>
> > Greetings!
> >
> > I'm work on implementing make(1), and I have two
> > questions for you:
>
> Why make and not mk?
They are not compatible and make(1) is used almost
NIH
On 2/3/17, Joshua Haase wrote:
> Mattias Andrée writes:
>
>> Greetings!
>>
>> I'm work on implementing make(1), and I have two questions for you:
>
> Why make and not mk?
>
>
Mattias Andrée writes:
> Greetings!
>
> I'm work on implementing make(1), and I have two questions for you:
Why make and not mk?
On Thu, 2 Feb 2017 20:08:04 +
Connor Lane Smith wrote:
> On 2 February 2017 at 19:54, Markus Wichmann
> wrote:
> > GNU make style patsubst rules, i.e.
> >
> > %.o: %.c
> > $(CC) $(CFLAGS) -o $@ $<
> >
> > Those are really useful.
>
> While GNU's
On 2 February 2017 at 20:08, Connor Lane Smith wrote:
> > .o:
> > $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $<
By which I of course mean `.c:'. We're all making mistakes today!
cls
On 2 February 2017 at 19:54, Markus Wichmann wrote:
> GNU make style patsubst rules, i.e.
>
> %.o: %.c
> $(CC) $(CFLAGS) -o $@ $<
>
> Those are really useful.
While GNU's syntax can be more general, that rule can be done in POSIX make:
> .c.o:
> $(CC) $(CFLAGS)
On Thu, 2 Feb 2017 20:54:45 +0100
Markus Wichmann wrote:
> On Thu, Feb 02, 2017 at 06:45:49PM +0100, Mattias Andrée
> wrote:
> > Greetings!
> >
> > I'm work on implementing make(1), and I have two
> > questions for you:
> >
> > 1) What extensions do you think I shall
On Thu, Feb 02, 2017 at 06:45:49PM +0100, Mattias Andrée wrote:
> Greetings!
>
> I'm work on implementing make(1), and I have two questions for you:
>
> 1) What extensions do you think I shall implement? I think I will
>add $(foreach), $(shell), and I will definitely add $(SHELL).
>
Greetings!
I'm work on implementing make(1), and I have two questions for you:
1) What extensions do you think I shall implement? I think I will
add $(foreach), $(shell), and I will definitely add $(SHELL).
$(SHELL) is the macro that use to select the shell to use, POSIX
only
23 matches
Mail list logo