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
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
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
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
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
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 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 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
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:
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
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
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
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
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 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
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
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
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
$(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
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
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 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
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
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
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
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
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
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
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
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
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
"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
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
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
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.
>
>
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
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
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 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
$(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?
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
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
>
> >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
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
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
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
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
-- Forwarded message --
From: Tim Murphy
Date: 5 January 2015 at 17:20
Subject: Re: Dynamic adjustments of build dependencies for the number of
available processors
To: SF Markus Elfring
Hi
On 5 January 2015 at 17:03, SF Markus Elfring wrote:
>
> > I'm sor
This sounds like an extremely useful debugging feature. I have often
had the problem of getting the wrong build parameters but not being
sure exactly why because of the great complexity of makefiles that are
trying to build many different sorts of object files all with slight
variations that are
We cannot help you if you don't post your makefile. Every makefile is
different and nobody can give you an answer that is guaranteed to work
without seeing it.
You might be lucky if you set LDFLAGS e.g. to "-lmysqlcppconn" but
this could easily not be correct.
Regards,
Tim
On 20 June 2014 07:37
On 24 February 2014 18:33, Paul Smith wrote:
> I would definitely want this to be totally invisible to the user and not
> require any magic in makefiles (so no special include operator, etc.)
> Basically it should either be so safe that there's no way to tell the
> difference between using the co
E and then use that in every
submake to get the relative start time.
I haven't looked at the patch - perhaps it's doing this?
In any case, fixed/floating point seconds since 1970 is the nicest
format to process from scripts in my experience.
Regards,
Tim
On 14 January 2014 15:49, Tim Murp
To some, using a spreadsheet might not seem like the most worthwhile
way to visualise timing information.
If it was me, I'd be far more concerned about whether I could write a
script that could easily cope with all this information. Builds with
hundreds of thousands of targets were common for me
It's nice to know when in the build a job was scheduled. e.g I have a
huge job that gets scheduled at the end of the build - wouldn't it be
nicer if it was scheduled at the beginning? Perhaps I can redesign my
makefile to achieve that if I know.
On 11 January 2014 18:58, Paul Smith wrote:
> Sorr
On 15 December 2013 16:07, Paul Smith wrote:
> In other words, I prefer to take a page from Git, GDB, and other
> projects where the default output is human readable but probably not
> easily parsed by tools, and then provide a different output format
> option that provides machine-parse-able for
arge build system and
it was easy to parse and produced a lot of useful data for us which
would have been exceedingly difficult to do without a structured
output format.
Cheers,
Tim
On 15 December 2013 13:38, Tim Murphy wrote:
> I suppose I'm skirting around saying that I think gnu make
seconds
where the precision might vary depending on the architecture and OS.
Anyhow it's just my 2p.
Cheers and merry christmas,
Tim
On 15 December 2013 09:00, Eddy Petrișor wrote:
>
> Pe 29.11.2013 12:30, "Tim Murphy" a scris:
>
>
>>
>> When I
prints out something similar to what I'm
looking for. I also like it when the format is such that it can
change a bit without necessarily forcing me to rewrite my parser.
Again, this is only an opinion - it carries no weight.
Regards,
Tim
On 29 November 2013 02:43, Eddy Petrișor wrote:
>
FWIW
As for profiling output, this should probably go to a file (possibly
with a .PID on the end) , not stdout .unless. you start to
embrace the idea of structured output for everything that make
produces.
I have used XML before and it has advantages, not the least of which
is that it is
> Me too. I think we all basically agree that all of the above can be
> useful, we just disagree on how hard each is to implement. I'm not
> so sure these "very few little enabling features" are really such
> small changes, whereas I think ordered output and/or individual log
> files are easier to
while the
>> rest of the build runs, ready for the next incremental.
>
> Of course, for similar reasons we now have different levels of
> output-sync, and that's why I think ordering can be seen as yet
> another one of those levels.
>
> Tim Murphy wrote:
>
>> The
I think this is something that's difficult to do and somewhat beside the point.
It's lucky if you're someone for whom two builds even have all the
same targets or all the same dependencies.
The idea of diffing 2 builds is truly a cool one - especially when
they're huge - but I'd rather it was don
forgot to cc the list - oops.
-- Forwarded message --
From: Tim Murphy
Date: 5 September 2013 14:30
Subject: Re: [bug #39943] Add an alternative parsing mode that regards
space and tab as identical tokens
To: "Paul D. Smith"
warning and finally enforcement of
d finally enforcement of something.
Regards,
Tim
On 5 September 2013 11:18, Tim Murphy wrote:
> ah, interesting - good point. My standard (at least the enforced
> standard where I work) is 4-spaces and it doesn't catch that.
>
> On 5 September 2013 10:44, Eli Zaretskii wrote:
ah, interesting - good point. My standard (at least the enforced
standard where I work) is 4-spaces and it doesn't catch that.
On 5 September 2013 10:44, Eli Zaretskii wrote:
>> Date: Thu, 5 Sep 2013 10:38:16 +0100
>> From: Tim Murphy
>> Cc: Byron Hawkins ,
>>
spaces-for-tabs bugs are pretty common and very annoying though.
If it's not your editor then it's some stupid website or wiki page
that one puts example makefiles into. Or one types the example but
theres no way to insert a tab since it takes you to the next field.
Then people cut and past the
One thing that's worth thinking about in advance about the load directive
is whether there needs to be a way to pass parameters into modules.
In my case I need for the module to be able to know whether it's allowed to
generate debug output or not. I can think of many other areas in which I
might
I've done the "external utility" solution and only because we absolutely
had no other choice - it's not much fun and can be done much more
effectively by make itself.
Regards,
Tim
On 3 May 2013 14:16, Eli Zaretskii wrote:
> > From: Paul Smith
> > Date: Fri, 03 May 2013 08:57:57 -0400
> > Cc:
One optimisation I have thought of in the past for this situation would be
to allow a single "job" to hold onto the lock when it obtained it.
This way it could output directly to the console while all other jobs would
have to buffer. When it released, the next job lucky enough to grab the
lock mi
make second guessing your
decisions.
Regards, Tim
On 30/04/2013, Paul Smith wrote:
> On Tue, 2013-04-30 at 17:48 +0100, Tim Murphy wrote:
>> i.e. I don't just have
>> load X.dll
>
>> I have to supply the recipe to build it on windows:
>
>> X.dll:
>>
On 30 April 2013 17:28, Eli Zaretskii wrote:
>
> > Since you can't (in my recent experience) load a 64-bit DLL into a 32-bit
> > program, the real issue is what architecture was make itself built with.
>
> That's unrelated. I was talking about the fact that
>
> load foo.so
>
> is inherentl
t the log of a build you did yesteday? It's still very
nice to be able to distinguish things by colour later on.
Regards,
Tim
On 30 April 2013 11:16, Stefano Lattarini wrote:
> On 04/30/2013 12:01 PM, Tim Murphy wrote:
> > What I mean is that:
> >
> > ./make -
What I mean is that:
./make -Otarget
might be a good interactive default rather than -Omake.
Colouring is another issue which I would imagine could be done another way
to let us have the best of both worlds.
Regards,
Tim
On 30 April 2013 10:55, Tim Murphy wrote:
> I'm guessing he
I'm guessing here but I imagine the main problem comes with delaying the
results of submakes?
I haven't tested to see if this is how the new feature works or not. I
don't think it's completely necessary to keep all output from one submake
together. so turning that off might make things more intera
s,
Tim
On 30 April 2013 03:38, Eli Zaretskii wrote:
> > From: Paul Smith
> > Cc: Tim Murphy , bug-make@gnu.org
> > Date: Mon, 29 Apr 2013 16:34:01 -0400
> >
> > On Mon, 2013-04-29 at 22:34 +0300, Eli Zaretskii wrote:
> >
> > > > Yes, that s
On 29 April 2013 20:12, Eli Zaretskii wrote:
> > Date: Mon, 29 Apr 2013 18:19:09 +0100
> > From: Tim Murphy
> > Cc: "Paul D. Smith" , "bug-make@gnu.org" <
> bug-make@gnu.org>
> >
> > > 2. The fact that the dynamic object's file
wrote:
> > Date: Mon, 29 Apr 2013 19:33:10 +0100
> > From: Tim Murphy
> > Cc: Eli Zaretskii , "bug-make@gnu.org"
> >
> > Come now - the broken excuse is an excuse. There's plenty of crap free
> > software out there and some poor bastard trying
Guenther wrote:
> On Mon, Apr 29, 2013 at 10:30 AM, Tim Murphy wrote:
> > cc fred.c -c -o fred.o
> > cc bob.c -c -o bob.o
> > error on line 20 -X
> > error on line 30 -
> > error on line 330 -
> > makefile:342: recipe for target 'fred.o
I must clarify - I think that make should provide plugins with an
allocation mechanism. Not the other way around.
the snprintf model for dealing with expansion is not so bad - I mean the
problem is that nobody knows how big an expansion is going to be in the
end, right? So how does make deal wit
gt; > Date: Mon, 29 Apr 2013 16:40:03 +0100
> > From: Tim Murphy
> > Cc: "bug-make@gnu.org"
> >
> > cc fred.c -c -o fred.o
> > cc bob.c -c -o bob.o
> > error on line 20 -X
> >
> > Which one?
>
> Make will actually tell you w
Sorry to keep adding in my 2c but I have also submitted a plugin
implementation so I have a couple of ideas
On 29 April 2013 17:33, Eli Zaretskii wrote:
>
> 2. The fact that the dynamic object's file extension (.so) is exposed
>to the Makefile is unfortunate, because it will hurt portabilit
On 29 April 2013 16:19, Eli Zaretskii wrote:
> > Date: Mon, 29 Apr 2013 09:58:50 +0100
> > From: Tim Murphy
> > Cc: "bug-make@gnu.org"
> >
> > try interpreting error messages from compiler/tool X when they're 10
> > lines from the file that
Let me add my voice as a user. If you are one of the lucky people whose
builds consist mostly of 1 line of output per rule then you will rarely
have any trouble in a good build but try interpreting error messages from
compiler/tool X when they're 10 lines from the file that they refer to and
don't
On 25 April 2013 20:06, Eli Zaretskii wrote:
> > Date: Thu, 25 Apr 2013 19:36:28 +0100
> > From: Tim Murphy
> > Cc: "bug-make@gnu.org"
> >
> > 1) sem_timedwait() in posix lets you timeout so in a big build when
> > something crashes or jus
ugh.
Regards,
Tim
On 25 April 2013 19:12, Paul Smith wrote:
> On Thu, 2013-04-25 at 07:14 +0100, Tim Murphy wrote:
> > To be honest, I have done all this before with named semaphores
> > including the "file that gets left over" problem and it's all solvable
> >
-- Forwarded message --
From: Tim Murphy
Date: 25 April 2013 07:13
Subject: Re: [bug #33138] .PARLLELSYNC enhancement with patch
To: "Paul D. Smith"
To be honest, I have done all this before with named semaphores including
the "file that gets left over"
why not use a named semaphore wherever possible (windows and linux) and
lock a file where not instead of trying to pass kernel object handles
around (seems a bit nasty to me)?
On 24 April 2013 21:19, Paul Smith wrote:
> On Wed, 2013-04-24 at 22:39 +0300, Eli Zaretskii wrote:
> > > Nothing is ac
Some time ago when solving the same problem in a different way we used
semaphores on Windows and Linux. Compatibility might make it less
interesting but I would suggest pretending that one has semaphores first
with some nice little abstraction and then implementing them in the best
way the platform
_OUTPUT=endrule $@ $(timestamp)
Then I'd use my plugin skills to write a $(timestamp) function.
Regards,
Tim
On 16 April 2013 13:43, Paul Smith wrote:
> On Tue, 2013-04-16 at 09:57 +0100, Tim Murphy wrote:
> > When most rules are a single job this doesn't seem important but
o see where one rule ended and the next one began.
When most rules are a single job this doesn't seem important but when
you're doing anything non trivial it becomes hard to see what is where.
Regards,
Tim
On 16 April 2013 09:56, Tim Murphy wrote:
> This is an awesome feature, esp
ind a better explanation than I can
give.
Regards,
Tim
On 11 April 2013 19:35, David Sankel wrote:
> On Thu, Apr 11, 2013 at 12:31 PM, Tim Murphy wrote:
>
>> There are commercial emulations of GNU make that can handle multiple
>> outputs. I don't want to plug them becaus
There are commercial emulations of GNU make that can handle multiple
outputs. I don't want to plug them because that might be annoying. It's
just worth mentioning that it can be done.
Regards,
Tim
On 11 April 2013 11:14, Reinier Post wrote:
> On Thu Apr 4 16:17:58 2013, psm...@gnu.org (Paul
It would be nicest to actually use git (or if we were in heaven, Mercurial)!
:-)
Cheers,
Tim
On 3 January 2013 20:20, Frank Heckenbach wrote:
>> > BTW, I wanted to check against the current repository version, but
>> > when I tried to fetch it as described on
>> > https://savannah.gnu.org/git/?
Hi :-)
This is a response to a rather old email about loadable modules.
I'm keen to see the patch for the load operator if you have it :-).
On 5 April 2012 15:12, Paul Smith wrote:
> Before going too much further note that I've got a semi-implemented
> "load" operator in my source already, whi
"
wrote:
> On 08/11/2012 07:36 AM, Tim Murphy wrote:
> > This is a different thing but I'd have had great use for a way to tell
> if a
> > target had been defined previously. Had to use variables to do it which
> > used a lot of memory and it was a total w
This is a different thing but I'd have had great use for a way to tell if a
target had been defined previously. Had to use variables to do it which
used a lot of memory and it was a total waste because make has the
information already.
Perhaps the ability to detect if a target is defined and anoth
Using targets to make subdirectories is problematic, imho, since the
timestamps on the directory don't have any particular meaning. This is a
case of recursive maake being harmful.
If it was me, the dependency would be on the .a file, not on the directory.
all: $(TARGETS)
Target1: adir/lib1.a b
Knowing make's current idea of where it is would still be nice even if
it keeps changing.
I also would like to hook to the start and end of the execution of
every recipe because there are many uses for this, one of which might
be progress but triggering retries (when unreliable network shares are
Hi,
Use the -n option.
make -n
This shows what would happen but doesn't do anything. It's not
precisely what you want but it's the closest thing.
Regards,
Tim
On 1 May 2012 10:46, ?? wrote:
> Hello, my english not vell.
> I try to explain my tack.
> I need go get file names
On 6 April 2012 21:55, Eli Zaretskii wrote:
>> From: Paul Smith
>> CC: David Boyce , bug-make@gnu.org
>> Date: Fri, 6 Apr 2012 16:13:47 -0400
>>
>> Maybe this is just irrational prejudice but I've never had a good
>> experience using libtool and I'm SO uninterested in fighting with it in
>> GNU m
1 - 100 of 147 matches
Mail list logo
