Re: Ability to print the make database as json - experimental

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

Re: Ability to print the make database as json - experimental

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

[bug #64571] Add option to print targets

Follow-up Comment #18, bug#64571 (group make): Amazing, thank you Paul! And I agree with David A. Wheeler - this option makes sense for things like command line autocomplete. JSON makes sense for things like IDE integration. ___ Reply to

[bug #64571] Add option to print targets

Follow-up Comment #14, bug#64571 (group make): I think JSON would be a good solution. > (b) these tools (like jq for example) are not part of most standard systems and so can't be relied on to exist everywhere, It's no harder to install `jq` than it is to install `make` these days, even on relat

[bug #64571] Add option to print targets

Follow-up Comment #7, bug#64571 (group make): To be honest I'm not sure I know enough about Make to answer in detail, but generally people want to know targets for which they might actually type `make thetarget`, so: > I assume users only care about explicit targets, not implicit targets (pattern

Re: Ability to print the make database as json - experimental

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

Ability to print the make database as json - experimental

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

Re: [bug #64571] Add option to print targets

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 demande

[bug #64571] Add option to print targets

Follow-up Comment #4, bug #64571 (project make): > I'm just not really that convinced that the simplest thing is going to be useful to people. People are already using hacky regexes which are even less useful. > even internal ones etc Yeah there were some internal targets that I didn't want to

Re: [bug #64571] Add option to print targets

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

[bug #64571] Add option to print targets

Follow-up Comment #2, bug #64571 (project make): @mrsquee yeah I also found it confusing since there are some open patches but "Submit new" is disabled with no clue why. I think I read somewhere that they want you to just submit bugs with a patch attached, so that's what I did. Very unintuitive.

[bug #64571] Add option to print targets

: None ___ Follow-up Comments: --- Date: Sat 19 Aug 2023 05:49:19 PM UTC By: Tim A *lot* of people would like to be able to print all the targets contained in a Makefile. Here's the most popular St

Re: [bug #62936] Confusing description of chained rules in the manual

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

Re: [bug #62936] Confusing description of chained rules in the manual

x27;s happening. Just to give you an example: >> The first difference is what happens if the intermediate file does >> not exist. If an ordinary file b does not exist, and make considers a >> target that depends on b, it invariably creates b and then upcreates >> the target from b. But if b is an intermediate file, then make does >> not bother upcreting b, or the ultimate target, unless some >> prerequisite of b is newer than that target or >> there is some other reason to update that target. Regards, Tim

Re: [PATCH v4] Add '--shuffle' argument support

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 wr

Re: [bug #61594] suggest new $(hash ...) function

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,

Re: [bug #61594] suggest new $(hash ...) function

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

Re: math expressions (was: Re: Tail call elimination)

n, so yes. Integer maths is important at the language level - it will enable algorithms that weren't possible before e.g. dividing a list into equal halves or a for-loop for which we also need a function that generates a range). To me this seems to be on a higher level of importance compared to bit manipulation. Tim

Re: math expressions (was: Re: Tail call elimination)

gt; > If at all possible, I think. Tim

Re: Tail call elimination

ch for "op" or "math" in my code.. I have not found it very useful to search for "+" or '"-" in other languages so why in make? Surely to improve readability you can define functions which do common computations and search for their names? Regards

Re: Tail call elimination

t some error cases to be expressed which could be undesirable e.g. $(/ 1 2 3) could be a bit ambiguous or at least an unwanted possibility. Regards, Tim

Re: Tail call elimination

this is roughly the way make operations work now you can avoid inventing a lot of rules about what you "might need" in future. Regards, Tim

Re: Tail call elimination

chance of creating a carbuncle. Regards, Tim Regards, Tim On Tue, 19 May 2020, 14:26 Paul Smith, wrote: > On Mon, 2020-05-18 at 21:40 -0400, Daniel Herring wrote: > > This decision causes a difficult and error-prone ambiguity when the > > return value is really true and empty.

Re: Tail call elimination

huge difference. Regards, Tim On Mon, 18 May 2020 at 19:39, Paul Smith wrote: > On Mon, 2020-05-18 at 21:05 +0200, Jouke Witteveen wrote: > > On Mon, May 18, 2020 at 8:50 PM Paul Smith wrote: > > > > > > On Mon, 2020-05-11 at 16:32 -0500, Pete Dietl wrote: > > >

Re: Tail call elimination

$(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 t

Re: Tail call elimination

e GMSL was gross. Regards, Tim On Mon, 18 May 2020, 18:57 Pete Dietl, wrote: > > It should not be necessary for the use-cases of make > > I assert that arithmetic functionality does have use-cases in Make. > Beyond building, I use Make for packaging my software and running tests. >

Re: Tail call elimination

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

Re: Feature request / patch: dependency-only prerequisites

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 th

Re: Idea: Allow $(name ...) as an abbrevation of $(call name ....)

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

Re: Idea: MAKE_SILENCEWARNINGS variable silences make warnings

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

Re: Idea: Allow $(name ...) as an abbrevation of $(call name ....)

arges on to the end, evaluating blindly to who knows what and we can spend hours trying to tease out the cause of a missing compiler option but.we are focused on the saving of a tiny bit of typing. . Regards, Tim On Tue, 11 Jun 2019 at 14:09, David A. Wheeler wrote: > On Tue, 11

Re: Idea: Add command-line option for reporting potential makefile errors

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 b

Re: Idea: Allow $(name ...) as an abbrevation of $(call name ....)

g the time on some of your other proposals which get around really significant problems. Regards, Tim On Mon, 10 Jun 2019 at 04:46, David A. Wheeler wrote: > On Mon, 10 Jun 2019 11:56:04 +0900, Masahiro Yamada > wrote: > > It is a design. > > Sure, but we can add to it. >

Re: GNU Make for Java projects

children. I have, quite literally, gone grey haired waiting for it. So my advice is to to do anything except wait. Regards, Tim On Tue, 12 Feb 2019, 04:13 Blake McBride I appreciate all of the replies and comments, but I think a point is being > missed. > > Let's say my Java app

Re: function uniq in make

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, &g

.LIBPATTERNS doesn't work with pattern rules !?

/tmp/libxxx.a exists.) $ make -v GNU Make 4.2.1 Built for x86_64-pc-linux-gnu The error message is 'make: *** No rule to make target...'. Please reply with me in CC (not subscribed curently). Thanks for any input. Regards, Tim signature.asc Descript

Re: Regression caused by Commit: 5bd7ad2b225b ("Preserve the real value of -jN in MAKEFLAGS using jobserver.")

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: > >

Re: [bug #52209] Support for ifeq function

the function before asking it to be added and of course you can provide a patch. Regards, Tim On 12 October 2017 at 07:26, anonymous wrote: > Follow-up Comment #3, bug #52209 (project make): > > Thanks Paul for dealing with this so quickly. > > For the benefit of clarity

Re: [PATCH 1/2] Trivial correction on document

"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

Re: thoughts and questions on order-independent Makefile method

ile rather than submakes. There's always ninja if you decide you want to generate makefiles from some other language. Regards, Tim On 2 May 2017 at 09:03, Martin Dorey wrote: > I've had the same frustrations, though you've got further in some > directions than I hav

Re: question

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 : > Bo

Re: INTERNAL: Exiting with 2 jobserver tokens available; should be 5!

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. > >

Re: INTERNAL: Exiting with 2 jobserver tokens available; should be 5!

Linux. For more details see the release notes <http://valgrind.org/docs/manual/dist.news.html>." I don't know what the gcc version is on your Pi but if you have a recent enough one you might manage to use the address sanitiser option to get a similar result. Regards, Tim On 12 No

Re: reverse dependency order?

at feasible? Would it be easy to implement? I asked that exact question in 2012 (http://permalink.gmane.org/gmane.comp.gnu.make.general/10601) and even then there had already been requests for that "in the past" :-). I wrote a basic patch to reverse or random- ize the order (http://permalink.gman

Re: Order of expansion of recipe lines

@$(info there) > > or indeed : all: @mkdir output; $(file stuff>>output/file.txt) Just to point out the obvious that this change wouldn't remove the need to understand the order of expansion. Regards, Tim ___ Bug-ma

Re: Order of expansion of recipe lines

> to run that line. > > I dunno. Opinions? > > I think the whole idea of combining functions-with-side-effects and shell commands should be heavily discouraged. It's one more area for parallelism issues to creep in. Regards, Tim ___

Re: $(file) can't read files

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) can't read files

$(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?

Re: Parallel make

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

Re: Using hash instead of timestamps to check for changes.

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

Re: Using hash instead of timestamps to check for changes.

ost obvious use for customisable "uptodateness" would be the trick used in the Meson build system where there's no need to relink some code if a library changes unless the API of the library has changed. This is exceedingly powerful because linking is a slow activity and it reads a lot of

Re: Difficulties from the combination of functions "call" and "eval"

gards, Tim On 18 Jan 2015 21:07, "Norbert Thiebaud" wrote: > On Sun, Jan 18, 2015 at 6:31 AM, SF Markus Elfring > wrote: > > > > Yes. - The evaluated variable should produce shell commands for recipes. > > I try to reuse it as a subfunction. > > then use $

Re: Visualisation of make files as graphs

. Regards, Tim On 12 January 2015 at 17:04, SF Markus Elfring < elfr...@users.sourceforge.net> wrote: > Hello, > > Make files can grow to a size (with all their build rules > and various script code) where it becomes harder to follow > the involved data processing structure

Re: Better description for "define"?

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 > "de

Re: Dynamic adjustments of build dependencies for the number of available processors

rs there were like this (linux): NPROC:=$(shell grep "processor" /proc/cpuinfo | cut -b12- ) # this returns "0 1 2 3" etc # Then you might use eval to generate rules dynamically: $(foreach N,$(NPROC),$(eval # YOUR DYNAMIC RULE MYTARGET_$(N): mytool --dosomething -o$@

Fwd: Dynamic adjustments of build dependencies for the number of available processors

-- 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

Re: [PATCH v2 1/6] * expand.c (variable_name_extract): extract variable name and strip prefix.

unless the commandline option is on. As for whether the implementation is correct or optimal or fits make standards or whether it should really be part of the core gnumake (instead of being some sort of frequently updated patch/fork) I don't know. Regards, Tim On 21 August 2014 08:25, Macpau

Re: compile using make!

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

[bug #40344] Can't handle Windows path names longer than 259 characters

Follow-up Comment #9, bug #40344 (project make): Vladimir, when will your patch be ready? ___ Reply to this item at: ___ Nachricht gesendet von/durch Sa

[bug #41830] make cannot find an existing file

URL: Summary: make cannot find an existing file Project: make Submitted by: nasf82309 Submitted on: Di 11 Mär 2014 07:50:30 GMT Severity: 3 - Normal Item Group: Bug

Re: Bug-make Digest, Vol 135, Issue 17

nags and abandon the whole effort when the initial subcase would have worked. Regards, Tim -- You could help some brave and decent people to have access to uncensored news by making a donation at: http://www.thezimbabwean.co.uk/friends/ ___ Bug-make m

Re: [bug #40639] GNU Make with profiling information

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

Re: [bug #40639] GNU Make with profiling information

mation. e.g. if you keep information from a previous build and combine it with profiling information coming out of the new build you can guess how long is left. Regards, Tim On 14 January 2014 13:48, Eddy Petrișor wrote: > > > 2014/1/12 Paul Smith : > >> On Wed, 2013-12-18 at 13:2

Re: [bug #40639] GNU Make with profiling information

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

Re: [bug #40639] GNU Make with profiling information

d generate a table that allowed one to jump directly to the point in a log where some file was mentioned or where some error occurred. When builds get really big this would be nice as even grep can be overwhelmed by something large enough. I have gone off-topic. I apologise. Regards, Tim -- You co

Re: [bug #40639] GNU Make with profiling information

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

Re: [bug #40639] GNU Make with profiling information

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

Re: [bug #40639] GNU Make with profiling information

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: >

Re: [bug #40639] GNU Make with profiling information

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

Re: [bug #40225] Deterministic output ordering

> 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

Re: [bug #40225] Deterministic output ordering

e human readable output - users can even choose which filters to apply or they can apply them after the build is over to a log file and look at it in different ways. There's not much make needs to do here - most of this is for other tools to do - it only has to support a very few little enabl

Re: [bug #40225] Deterministic output ordering

It's like putting slick types on a 1920s car - it might help but it's still a long way off modern designs. Regards, Tim On 10 October 2013 06:29, Frank Heckenbach wrote: > Paul D. Smith wrote: > >> A non-parallel build is actually fully deterministic for a given mak

Fwd: [bug #39943] Add an alternative parsing mode that regards space and tab as identical tokens

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

Re: [bug #39943] Add an alternative parsing mode that regards space and tab as identical tokens

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:

Re: [bug #39943] Add an alternative parsing mode that regards space and tab as identical tokens

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 , >>

Re: [bug #39943] Add an alternative parsing mode that regards space and tab as identical tokens

d past the example and it messes up in an extremely odd way. It would be nice even if make was able to guess what might be happening and issue a warning (although in a way I think one might well go the whole hog). Regards, Tim On 4 September 2013 23:32, Paul Smith wrote: > On Wed, 2013-0

load directive - module parameters

hook so that it can deallocate resources cleanly. Cheers, Tim -- You could help some brave and decent people to have access to uncensored news by making a donation at: http://www.thezimbabwean.co.uk/friends/ ___ Bug-make mailing list Bug-make@gnu.org h

Re: Another issue with -O?

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, 0

Re: Some serious issues with the new -O option

b the lock might have a full buffer already. It might appear to be less choppy. Not sure how it would perform. Regards, Tim On 2 May 2013 03:53, Eli Zaretskii wrote: > > From: Paul Smith > > Cc: stefano.lattar...@gmail.com, bug-make@gnu.org > > Date: Wed, 01 May 2013 16

Re: dynamic object searching (was: Re: Dynamic objects)

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: >>

Re: dynamic object searching (was: Re: Dynamic objects)

t indicate whether the plugin is 32 or 64 bit. So to me it just seems like a complication because it can't solve the whole problem that make generally needs explicit effort to support builds on multiple platforms. Regards, Tim -- You could help some brave and

Re: Some serious issues with the new -O option

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 -

Re: Some serious issues with the new -O option

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

Re: Some serious issues with the new -O option

ght make things more interactive, Per-target syncing is a valid compromise. Regards, Tim On 30 April 2013 10:48, Stefano Lattarini wrote: > I'm sorry to say that the new -O option can interact *badly* > with Automake-generated parallel testsuites (at least when they > are being run

Re: dynamic object searching (was: Re: Dynamic objects)

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. It's sort of a matter of make identifying itself rather than telling you that you're running on ubuntu 13.04 or solaris 10. Regard

Re: Dynamic objects (was: .ONESEHLL not working as expected in 3.82)

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

Re: Default output-sync setting (was: Re: [bug #33138] .PARLLELSYNC enhancement with patch)

One doesn't have to suffer the problems and learn the option exists afterwards. In the end I can understand why a new feature might not be default to start with - until a lot of people have used it and are sure that it works everywhere. Cheers, Tim On 29 April 2013 20:21, Eli Zaretskii

Re: Default output-sync setting (was: Re: [bug #33138] .PARLLELSYNC enhancement with patch)

Come now - the broken excuse is an excuse. There's plenty of crap free software out there and some poor bastard trying to build it who can't change the source because the people who own it think it should be make's problem. :-) Cheers, Tim On 29 April 2013 19:00, Philip

Re: Dynamic objects (was: .ONESEHLL not working as expected in 3.82)

with this already? The same way would be fine for the plugin and it would be nice to not simply push that problem on to all plugin writers. Cheers, Tim On 29 April 2013 18:59, Paul Smith wrote: > On Mon, 2013-04-29 at 19:33 +0300, Eli Zaretskii wrote: > > > From: Paul Smith > &

Re: Default output-sync setting (was: Re: [bug #33138] .PARLLELSYNC enhancement with patch)

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' failed makefile:350: recipe for target 'bob.o' failed ? Regards, Tim On 29 April 2013 18:25, Eli Zaretskii wrote: &

Re: Dynamic objects (was: .ONESEHLL not working as expected in 3.82)

f (strcmp (funcname, "test-expand") == 0) return test_expand (argv[0]); if (strcmp (funcname, "test-eval") == 0) return test_eval (argv[0]); return strdup ("unknown"); } That strdup at the end should be a gmk_strdup() if possible. :-) Prob

Re: Default output-sync setting (was: Re: [bug #33138] .PARLLELSYNC enhancement with patch)

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

Re: Default output-sync setting (was: Re: [bug #33138] .PARLLELSYNC enhancement with patch)

ndroid build and you can make a decision after that? Heck, lets try it with various things and be happy it works. Regards, Tim On 29 April 2013 03:53, Eli Zaretskii wrote: > > From: Paul Smith > > Cc: bug-make@gnu.org > > Date: Sun, 28 Apr 2013 22:03:39 -0400 > > > &g

Re: Fwd: [bug #33138] .PARLLELSYNC enhancement with patch

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

Re: Fwd: [bug #33138] .PARLLELSYNC enhancement with patch

nd you pre-delete ones that by incredible luck might exist before make started and have the same name as the one you want to use. 4) In a way this makes the file-lock and semaphore mechanisms "look" rather the same - files in /tmp. This seems easier to understand. It's no big deal, tho

Fwd: [bug #33138] .PARLLELSYNC enhancement with patch

-- 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"

Re: [bug #33138] .PARLLELSYNC enhancement with patch

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

Re: [bug #33138] .PARLLELSYNC enhancement with patch

e top-level make executable's PID should be good enough. This is used to create the named semaphore. Platforms without semaphores might use a file and locking or if that doesn't work then they can't implement the feature and you configure it out. Regards, Tim On 24 Apr

Re: [bug #33138] .PARLLELSYNC enhancement with patch

_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

Re: [bug #33138] .PARLLELSYNC enhancement with patch

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

  1   2   >