On Sun, Jun 18, 2017 at 5:31 AM, Eli Zaretskii wrote:
> > From: Orgad Shaneh
> > Date: Sat, 17 Jun 2017 23:04:11 +0300
> > Cc: bug-make@gnu.org, Alexey Pavlov
> >
> > +#ifdef WINDOWS32
> > + for (e = 0; e < 10; ++e)
> > +{
> > +#endif
> > + status = unlink (file->name);
>
> From: Orgad Shaneh
> Date: Sat, 17 Jun 2017 23:04:11 +0300
> Cc: bug-make@gnu.org, Alexey Pavlov
>
> +#ifdef WINDOWS32
> + for (e = 0; e < 10; ++e)
> +{
> +#endif
> + status = unlink (file->name);
> +#ifdef WINDOWS32
> + if (status == 0 || errno == ENOENT)
> +
On Fri, Jun 16, 2017 at 7:36 PM, Eli Zaretskii wrote:
> > From: Orgad Shaneh
> > Date: Fri, 16 Jun 2017 17:05:58 +0300
> > Cc: "bug-make@gnu.org" , Alexey Pavlov <
> alex...@gmail.com>
> >
> > Ah, okay. But then the problem is not with child processes of g++,
> > it's with g++ itself, right?
>
> Sure, it could be made clear in the documentation that either of the
> sides of the "=" could be empty.
In how many source files should corresponding information be integrated
to make these special cases better known for substitution references?
> However, there are plenty of ways to do this s
On Sat, 2017-06-17 at 20:21 +0200, SF Markus Elfring wrote:
> > > my_test_command?=cat
> > >
> > > define my_rule_demo=
> > > name::=${1}
> > > $${name:.in=.txt}: ${1}
> > > $${my_test_command} $$< > $$@
> > > endef
> > >
> > > $(eval $(call my_rule_demo,MOTD.in))
> >
> > Is there someth
>> my_test_command?=cat
>>
>> define my_rule_demo=
>> name::=${1}
>> $${name:.in=.txt}: ${1}
>> $${my_test_command} $$< > $$@
>> endef
>>
>> $(eval $(call my_rule_demo,MOTD.in))
>
> Is there something wrong with it?
The answer depends on our views about approaches how customised
make func
On Mon, 2017-06-12 at 15:17 +0800, Cao jin wrote:
> I find some tiny errors in "info make", as a non-developer, I want to
> know how to provide the patch? Do you accept patch email via "git
> send-email"?
Any form in which you'd like to provide them, is acceptable.
Thanks!
_
On Sat, 2017-06-17 at 17:00 +0200, SF Markus Elfring wrote:
> It might also be expected that this simple example just can not work
> as intended because of a special typo (one dollar sign missing).
Well, as they say, GIGO :)
> Corrected example:
>
> my_test_command?=cat
>
> define my_rule_demo=
>> define my_broken_rule=
>> name::=${1}
>> ${name:.in=.txt}: ${1}
>> $${my_test_command} $$< > $$@
>> endef
>>
>> $(eval $(call my_broken_rule,MOTD.in))
>
> Yes, this will not work.
Thanks for your quick answer.
It might also be expected that this simple example just can not work
as in
On Sat, 2017-06-17 at 16:05 +0200, SF Markus Elfring wrote:
> my_test_command?=cat
>
> define my_rule=
> ${1:.in=.txt}: ${1}
> $${my_test_command} $$< > $$@
> endef
>
> $(eval $(call my_rule,MOTD.in))
>
> This result is fine. Please try the following approach out again.
>
> my_test_comm
> What Philip is saying (and I agree 100%) is that you provide the above
> example which is excellent and helpful and allows us to see exactly what
> you're doing. Thank you for that.
I was also curious in this case how the interest will evolve to clarify
the shown construction of make rules.
>
On Thu, 2017-06-15 at 17:18 +0200, SF Markus Elfring wrote:
> define rule_pair =
> name::=$(1)
> $$(name:.ml=.cmo): $$(name)
> $$(OCAMLC_CMD) -c $$<
>
> $$(name:.ml=.cmx): $$(name)
> $$(OCAMLOPT_CMD) -c $$<
> endef
>
> $(foreach x,$(SRC_without_mli),$(eval $(call rule_pair,$(x
> Could you provide examples of the Makefiles rules you tried?
It depends on the detail level you prefer and my tendency to increase
corresponding efforts only incrementally.
> It's very difficult to provide feedback without complete information.
Would you like to add any advice to a discussion
> Using ::= in a makefile which is already dependent on GNU make is, IMO,
> pointless.
I am trying to use portable make specifications to some degree.
But it seems to be challenging to avoid the usage of all the nice
functionality which is provided as extensions also by this software
development
> I believe the point of Martin's rhetorical query is "why should make treat
> the failure of *this* pattern rule any different than the failure of the
> many other pattern rules that would have permitted this compilation
> to complete?"
It seems that I need to try harder for the desired clarifi
>> I needed another moment to become really aware that this software module
>> is a bit special. It seems that it is intended that it will be compiled
>> without a corresponding interface description file (suffix “mli”).
>
> Well, I'm totally lost. Here's why:
>
> You told make ".cmo files can b
16 matches
Mail list logo
