On 5 January 2015 at 18:13, SF Markus Elfring wrote:
> > I assume that you want something different from this
> > but you need to explain better, sorry :-)
>
> I hope that an other wording will be clearer.
>
> Can make rules be extended on demand while a build script
> is evaluated?
>
> How much
define..endef allows you to assign multi-line values to a variable.
Regards,
Tim
On 6 January 2015 at 11:57, SF Markus Elfring wrote:
> > The "define" construct is already in the index.
>
> I am missing an explanation there for the aspect when the construct
> "define … endef"
> should be used
This is generally a hopeless thing to do because the graphs become enormous
spiderwebs.
Gephi is good enough to do large makefiles without crashing or slowing down
to a stop.
You can use "gmake --print-database -f Makefile" and then write a script
to convert that into .dot format which gephi wi
With eval and call one can get confused quite easily. Try changing eval to
info and then inspect the output to see if it makes sense as a makefile.
Write small test makefiles that do small aspects of what you want and build
them up step by step until you get the result you want when you introduce
a
>
> >My thinking is that the timestamp is in fact an overly conservative
> > test. We never have the case that the timestamp indicates something
> > *has not* been changed when in fact it has (i.e. we always build if
> > something has changed),
>
> That's interesting, because in my exper
On 11 April 2015 at 16:38, Enrico Weigelt, metux IT consult <
enrico.weig...@gr13.net> wrote:
> On 07.04.2015 00:17, Eric Melski wrote:
>
>
> > ClearCase
> > does this in various configurations, and Perforce will if your client
> > spec has "modtime" set. I'm sure other SCM systems can be setup t
Without wanting to turn this into a commercial/advert you might want to
consider trying the Electric Cloud Huddle beta since it works with multiple
machines in a convenient way and deals with the problems of getting correct
parallel builds. It is also free for now at least.
Sorry for that :)
On 29
$(file) offers the ability to write files which saves one from tricks
involving $(shell). Calling $(shell) is very slow indeed in some makefiles.
$(shell cat filename) is also often used to read files into variables.
There isn't much reason why $(file <) shouldn't read a file though is
there?
On 30 May 2015 at 19:02, Paul Smith wrote:
> On Wed, 2015-05-27 at 07:50 +0100, Tim Murphy wrote:
> > $(shell cat filename) is also often used to read files into variables.
> >
> > There isn't much reason why $(file <) shouldn't read a file though is
> &g
On 14 March 2016 at 14:22, Paul Smith wrote:
>
>
> I wonder if we shouldn't change the way we handle expansion of recipe
> lines to meet peoples' expectations: instead of expanding all recipe
> lines first we would expand recipe lines one at a time, as we got ready
> to run that line.
>
> I dunno
On 14 March 2016 at 14:22, Paul Smith wrote:
> Something that seems to be a constant source of confusion for users is
> the fact that GNU make expands the entire recipe first, before it starts
> any rules. Consider this recipe:
>
> all:
> @echo hi
> @$(info there)
>
>
or in
Something like Valgrind might spot some initial problem that doesn't
immediately crash but eventually spirals out of control. It seems to
support ARM linux now:
"20 October 2016: valgrind-3.12.0 is available. This release supports:
X86/Linux, AMD64/Linux, ARM32/Linux, ARM64/Linux, PPC32/Linux,
PPC
recent times.
Regards,
Tim
On 19 November 2016 at 22:03, Jaak Ristioja wrote:
> Hi!
>
> On 13.11.2016 07:37, Tim Murphy wrote:
> > Something like Valgrind might spot some initial problem that doesn't
> > immediately crash but eventually spirals out of control.
>
>
Excuse-mois, je ne parle pas le Francais bien mais si je vous comprend bien
vous avez utilisait l'option avec make mais ca c'est un option de f77.
Peut etre vous pouvez taper:
make FFLAGS="--N ftrap=common"
Bonne chance,
Tim
2016-12-28 9:44 GMT+00:00 rania rais :
> Bonjour,
>
>
> j'aimerais
If your build gets big enough you'll start to get to the point where the
single-process parse is longer than the parallel build so be a little
careful about how many evals you use - I'm speaking from experience. It
only matters if your build gets big though and if you use a single-makefile
rather
"that that" seems correct to me in this case and removing it incorrect.
There is a presumption and a conclusion and the sentence emphasises that
the conclusion is still presumed.
On 21 June 2017 at 06:38, Martin Dorey wrote:
> My native English speaker intuition says that "if it were" and "if it
Sorry for "plugging" my work but you can use loadable modules to implement
any function you like and I have done "ifeq" some time ago here:
https://bitbucket.org/tnmurphy/extramake
... except my version is $(equals...)
This is a good way to experiment with what you want from the function
before
For my money -j is always a top-level setting. To have it per makefile
and then let makefiles depend on that behaviour would open the door to lots
of scary bugs.
Regards,
Tim
On 29 October 2017 at 18:57, Paul Smith wrote:
> On Thu, 2017-09-28 at 16:28 +1000, NeilBrown wrote:
> > One of my Ma
You could try to write a new function and get it accepted but don't forget
that there is a mechanism for loadable modules that allows you to make
functions which can be dynamically loaded into an existing version of gnu
make.
Regards,
Tim
On Mon, 6 Aug 2018, 05:32 , wrote:
> Hi,
>
> I miss the
Targets with multiple outputs have never been well supported in GNU make
and despite appeals and the problem having existed forever and despite
examples of commercial make implementations that support it well, it would
not surprise me if support for it was something we could only hope for for
our c
If you can't make first-class functions that are the equal of $(filter) or
$(subst) or whatever, or indeed replace them, then it seems like a bit of a
fudge for the sake of 4 characters.
I think one could end up having huge discussions about this to a pretty
limited benefit and miss spending the t
If you use strace to detect dependencies you might have to do a thorough
patent search. I will say no more because it's not my place to.
Regards
Tim
On Wed, 12 Jun 2019, 03:09 David A. Wheeler, wrote:
> Problem:
>
> Makefiles often have errors, and they lay dormant because they're
> undetected
builtin functions can check their arguments to some extent. Interesting to
wonder if user defined ones can.
we don't even have $(equals) or a way to know the number of arguments that
were supplied or any mathematical operations with which to compare. So when
something is called wongly it charges on
Wouldn't it be safer to disable specific warnings for specific target(s),
or specific sections of a makefile?
On Tue, 11 Jun 2019 at 19:42, Paul Smith wrote:
> On Tue, 2019-06-11 at 14:37 -0400, David A. Wheeler wrote:
> > Create a new make special variable "MAKE_SILENCEWARNINGS".
>
> I have to
On Fri, 14 Jun 2019 at 03:17, Masahiro Yamada
wrote:
> On Fri, Jun 14, 2019 at 2:58 AM David A. Wheeler
> wrote:
> >
> > On Thu, 13 Jun 2019 18:18:15 +0100, Tim Murphy
> wrote:
> > > builtin functions can check their arguments to some extent.
> Interesting to
I quite like this idea because so many of us work on integrating things
that we have no permission to modify and we need ways to make them work
cleanly without messing them up. They are sort of "fix-up" or "patch"
dependencies. I'm not sure the name makes this clear though.
Regards,
Tim
On Sat
Yes we do want make to be a first class language and have had to put up
with it being a b*** a*** to do computations and impossibly slow to use
$shell.
Regards,
Tim
On Mon, 11 May 2020, 20:47 Daniel Herring, wrote:
> Hi Pete,
>
> I like your enthusiasm and understand the benefit. If this can
I have often wanted to auto generate targets with progressive numbers to
ensure uniqueness or count the number of times a particular macro is used
and most especially to compare two numbers to see if they are numerically
greater, less or equal.
Example: generating rules from potentially very long
$(shell) causes severe parse performance problems in large makefiles unless
you use it extremely sparingly.
[insert strong expression of frustration at make's deficiencies being
treated as blessed] :-)
Regards,
Tim
On Mon, 18 May 2020 at 19:18, Pete Dietl wrote:
> > Each of these has an ob
Re comparing strings: we already have ifeq and what I have often wanted is
to have a function equivalent so I can use it in expressions. As bad as
ifeq may be from the point of view of locale this need be no better to be
an improvement over the unpleasant hacks I've had to use to get the same
effec
A question would be do we want to use GMP or are 64 bit ints enough? I'm
inclined to say ints are ok of they are wide.
Sorry to jump to such a basic question. I sort of think it helps frame a
discussion about what people really want.
I mostly needed addition, comparison and decrement of values th
On Wed, 20 May 2020 at 15:47, Daniel Herring wrote:
> Hi Pete,
>
> My objections to GMP:
>
> - major added dependency (Make needs to be widely portable, and it is
> often part of a boot-strapping procedure. The core functionality needs to
> be trim. Heavy lifting needs to be separable.)
>
> - s
On Thu, 21 May 2020 at 13:08, Paul Smith wrote:
>
> > Other function syntax where there are "different" types of parameters
> > or arguments (i.e. subst, patsubst, findstring, filter, etc.), use a
> > syntax something like:
> >
> > $(math operator, value list)
> >
> > Consistent syntax patterns a
I don't fully understand these motivations, which is again not to say they
are not good - I just don't get them:
1) to implement everything in 1 function (or 2) - it seems like a slightly
artificial requirement - one that a user of the feature wouldn't think to
ask for.
2) documentation - again, pr
On Mon, 25 May 2020 at 18:34, Pete Dietl wrote:
> Question about 64-bit, what happens when compiling make for a 32-bit
> system? I don’t think c90 has `stdint.h`... maybe there’s something in
> gnulib. Anyway, would we want to support 64 bit integers even on 32-bit
> platforms?
>
> If at all poss
On Thu, 28 May 2020 at 22:07, Pete Dietl wrote:
> Upon taking a look at gnulib, I found that they have arithmetic wrap
> functions which guarantee wrapping.
> We can use these functions to guarantee that overflow will just wrap
> around.
>
> Let's leave the shift operators out for now.
>
> comp i
I have added such a function as a loadable library before - you might
consider that if you can't get it done another way.
https://github.com/tnmurphy/extramake
look at hash.c. To try it :
cd example && make -f example.mk
>
I called the function siphash24 because that's what I used - and its'
d
How does Python or Javascript manage with their map implementations that
use a hash to select a bucket?
One would want a low collision hash and that's really all that's needed to
make unique filenames from input data that would be too long to just
concatenate.
Regards,
Tim
On Sun, 5 Dec 2021 at
Ideally one would want to automatically learn about what depended on what
from recording the orders that were successful versus the orders that had
failures.
Regards,
Tim
On Sun, 20 Feb 2022, 12:25 Sergei Trofimovich, wrote:
> On Sun, Feb 20, 2022 at 10:30:10AM +, Sergei Trofimovich wrote:
On Sat, 15 Oct 2022 at 23:57, Paul D. Smith wrote:
> Follow-up Comment #1, bug #62936 (project make):
>
> I don't know why you say "you cannot update a non-existing file": make does
> this all the time! When you start make in a clean directory there are no
> object files, for example, and so tho
On Sat, 22 Oct 2022, 20:33 Paul Smith, wrote:
> On Wed, 2022-10-19 at 07:28 +0100, Tim Murphy wrote:
> > Outside of make "update" implies existence - we use CRUD as a term
> > for example not RUD. Why redefine the language? Actually for
> > databases the wor
On Wed, 1 Nov 2023 at 13:58, Paul D. Smith wrote:
> GNU Make is used by so many people for so many things, and I'm leery of
> creating some new facility that ends up being "not really right" for what
> people want to do, but that then must be maintained forever going forward.
>
It seems to me to
On Thu, 16 Nov 2023 at 09:11, Tim wrote:
> Follow-up Comment #4, bug #64571 (project make):
>
>
> > I'm just skeptical that this wouldn't degenerate into a morass of
> conflicting requests for new features.
>
> Maybe. But this is clearly a highly demanded feature just for
> auto-complete/dis
to keep everything separated for now.
I've also not mentioned that for the "MakefileName" in the example I
actually have inserted the contents of "$(MAKEFILE_LIST)" as that seems
more correct in a way.
There is an attached json produced by running on make itself - which is all
the testing I've done - this is a hack and probably needs real test data
and a load of tests.
Most of the code is in src/jprint.c. I had to export some things in
questionable ways and that is one of many reasons why I would never expect
this feature to get back into GNU make proper. I just think it can exist in
a fork and potentially be of use to someone.
Regards,
Tim Murphy
makefile-30281.json.gz
Description: application/gzip
t;
> generates illegal JSON:
>
Thanks for that - Ive made sure to use the string escaper with defines. :-)
You should see the changes pushed to the branch now
Thanks so much for taking a look at it!
Best regards,
Tim Murphy
ewriting makefiles - either as new makefiles or as some other build
system.
Regards,
Tim Murphy
On Thu, 28 Dec 2023 at 22:22, Tim Murphy wrote:
> Hi
> I've often wanted to extract information from a large build in some way
> that's more reliable than grep. The GNU ma
On Thu, 20 Mar 2025 at 21:07, David A. Wheeler
wrote:
>
>
> > On Mar 18, 2025, at 1:21 PM, Tim Murphy wrote:
> >
> > I've recently updated and rebased my experimental fork of make with the
> branch that dumps the internal database of the makefile to JSON for
Hi :-)
That's a cool idea. Can you send us the diff or a link to the diff?
Regards,
Timothy Murphy
On Wed, 2 Jul 2025 at 14:00, xf liao wrote:
> Hello everyone, my name is Nico, and I’m from China. I’m a senior IT
> systems architect, and I use Make in my daily work to build IT environments.
On Mon, 30 Jun 2025, 16:41 Zack Weinberg, wrote:
> Follow-up Comment #3, bug #67265 (group make):
>
> 1. The point of the bug report is that $(file) *should be* processed later
> than other $(...) constructs. Having said that, it would probably be
> sufficient, and perhaps a less invasive change
On Mon, 30 Jun 2025 at 18:14, Zack Weinberg wrote:
>
> p.s. I do insist that this is a bug, not a feature request. The existing
> behavior is strictly less useful than the requested behavior, and
> surprising
> to boot.
If I understand you then you want to use $(file) to get around the
command
On Wed, 2 Jul 2025 at 22:40, Bahman Movaqar wrote:
> Somehow in the same vein is the work I did in bmakelib:
> https://github.com/bahmanm/bmakelib/blob/main/doc/logged.md
>
That library is impressive.
I wondered if GNU make could benefit from a function that fetches the
current time - this migh
101 - 151 of 151 matches
Mail list logo
