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

; 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

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 demanded feature just for >

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

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

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

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

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

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, 5 Dec 2021

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'

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

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

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

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

Re: Tail call elimination

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,

Re: Tail call elimination

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

Re: Tail call elimination

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

Re: Tail call elimination

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

Re: Tail call elimination

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

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 these has an

Re: Tail call elimination

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

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

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 though. Regards, Tim On

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

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

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

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 because they're >

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

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

Re: GNU Make for Java projects

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

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

Re: [bug #52209] Support for ifeq function

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

Re: thoughts and questions on order-independent Makefile method

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

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

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

recent times. Regards, Tim On 19 November 2016 at 22:03, Jaak Ristioja <j...@ristioja.ee> 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

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

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,

Re: Order of expansion of recipe lines

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

Re: $(file) can't read files

On 30 May 2015 at 19:02, Paul Smith psm...@gnu.org 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 there? It would have the additional

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

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

Re: Difficulties from the combination of functions call and eval

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

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 elfr...@users.sourceforge.net wrote: The define construct is already in the index. I am missing an explanation there for the aspect when the construct define …

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

-- Forwarded message -- From: Tim Murphy tnmur...@gmail.com Date: 5 January 2015 at 17:20 Subject: Re: Dynamic adjustments of build dependencies for the number of available processors To: SF Markus Elfring elfr...@users.sourceforge.net Hi On 5 January 2015 at 17:03, SF Markus

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

On 5 January 2015 at 18:13, SF Markus Elfring elfr...@users.sourceforge.net 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

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

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

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 20 June 2014 07:37,

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

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

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

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

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

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

. Cheers and merry christmas, Tim On 15 December 2013 09:00, Eddy Petrișor eddy.petri...@gmail.com wrote: Pe 29.11.2013 12:30, Tim Murphy tnmur...@gmail.com a scris: When I did something similar (which I am not allowed to post) I made a new file for each submake and the output filename base

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

installed hence the error. Note the time flag.This was used in a very large 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

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

On 15 December 2013 16:07, Paul Smith psm...@gnu.org 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

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

27.11.2013 13:12, Tim Murphy tnmur...@gmail.com a scris: 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. The profiling info

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

mistakes so that I can start fixing them 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 idea

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

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

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 tnmur...@gmail.com 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 psm...@gnu.org warning and finally

load directive - module parameters

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

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 e...@gnu.org wrote: From: Paul Smith psm...@gnu.org Date: Fri, 03 May 2013

Re: Some serious issues with the new -O option

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

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

April 2013 03:38, Eli Zaretskii e...@gnu.org wrote: From: Paul Smith psm...@gnu.org Cc: Tim Murphy tnmur...@gmail.com, 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 should be possible. My concern

Re: Some serious issues with the new -O option

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

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 tnmur...@gmail.com wrote: I'm

Re: Some serious issues with the new -O option

not 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 stefano.lattar...@gmail.comwrote: On 04/30/2013 12:01 PM, Tim Murphy wrote: What I mean is that: ./make -Otarget might

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

On 30 April 2013 17:28, Eli Zaretskii e...@gnu.org 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

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

second guessing your decisions. Regards, Tim On 30/04/2013, Paul Smith psm...@gnu.org 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: cl.exe /Fdo$@ # use microsoft's compiler

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

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

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

On 29 April 2013 16:19, Eli Zaretskii e...@gnu.org wrote: Date: Mon, 29 Apr 2013 09:58:50 +0100 From: Tim Murphy tnmur...@gmail.com Cc: bug-make@gnu.org bug-make@gnu.org try interpreting error messages from compiler/tool X when they're 10 lines from the file that they refer

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

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 e...@gnu.org wrote: 2. The fact that the dynamic object's file extension (.so) is exposed to the Makefile is unfortunate, because it will hurt

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

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

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

...@gmail.com wrote: On Mon, Apr 29, 2013 at 10:30 AM, Tim Murphy tnmur...@gmail.com 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' failed makefile:350: recipe for target

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

...@gnu.org wrote: Date: Mon, 29 Apr 2013 19:33:10 +0100 From: Tim Murphy tnmur...@gmail.com Cc: Eli Zaretskii e...@gnu.org, bug-make@gnu.org 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 to build

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

On 29 April 2013 20:12, Eli Zaretskii e...@gnu.org wrote: Date: Mon, 29 Apr 2013 18:19:09 +0100 From: Tim Murphy tnmur...@gmail.com Cc: Paul D. Smith psm...@gnu.org, bug-make@gnu.org bug-make@gnu.org 2. The fact that the dynamic object's file extension (.so) is exposed

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

On 25 April 2013 20:06, Eli Zaretskii e...@gnu.org wrote: Date: Thu, 25 Apr 2013 19:36:28 +0100 From: Tim Murphy tnmur...@gmail.com Cc: bug-make@gnu.org bug-make@gnu.org 1) sem_timedwait() in posix lets you timeout so in a big build when something crashes or just sits around

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

-- Forwarded message -- From: Tim Murphy tnmur...@gmail.com Date: 25 April 2013 07:13 Subject: Re: [bug #33138] .PARLLELSYNC enhancement with patch To: Paul D. Smith psm...@gnu.org To be honest, I have done all this before with named semaphores including the file that gets left

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

Smith psm...@gnu.org 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 quite nicely. You pass the build id in the environment which is, after all

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

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

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 psm...@gnu.org wrote: On Wed, 2013-04-24 at 22:39 +0300, Eli Zaretskii wrote:

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

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 tnmur...@gmail.com wrote: This is an awesome feature, especially

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

a $(timestamp) function. Regards, Tim On 16 April 2013 13:43, Paul Smith psm...@gnu.org 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 when you're doing anything non trivial it becomes hard to see what is where

Re: Quirk with rules producing multiple output files

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 reinp...@win.tue.nl wrote: On Thu Apr 4 16:17:58 2013,

Re: Quirk with rules producing multiple output files

. Regards, Tim On 11 April 2013 19:35, David Sankel cam...@gmail.com wrote: On Thu, Apr 11, 2013 at 12:31 PM, Tim Murphy tnmur...@gmail.com wrote: 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

Re: Dependency violation in parallel build (3.82, regression)

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 f.heckenb...@fh-soft.de wrote: BTW, I wanted to check against the current repository version, but when I tried to fetch it as described on

Re: Patch to allow make to load plugins that add new functions.

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 psm...@gnu.org wrote: Before going too much further note that I've got a semi-implemented load operator in my source

Re: Feature request: silently overriding existing rules

...@gmail.com 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 waste because make has the information

Re: Feature request: silently overriding existing rules

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

Re:[bug #17873] .NOTPARALLEL enhancements

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

Re: Patch to allow make to load plugins that add new functions.

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

Fwd: How to get make result

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, ?? nonamelett...@gmail.com wrote: Hello, my english not vell. I try to explain my tack. I

Re: Patch to allow make to load plugins that add new functions.

Hi :-) On 6 April 2012 01:16, Paul Smith psm...@gnu.org wrote: On Thu, 2012-04-05 at 23:59 +0100, Tim Murphy wrote: I see the value in a plugin system as being that I don't have to recompile the plugins for every version of make. In a way it's tending towards why bother if you did have to do

Re: Patch to allow make to load plugins that add new functions.

On 6 April 2012 21:55, Eli Zaretskii e...@gnu.org wrote: From: Paul Smith psm...@gnu.org CC: David Boyce david.s.bo...@gmail.com, 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

Patch to allow make to load plugins that add new functions.

Hi, I am between jobs which made me realise that I am absolutely free to contribute to make for about 10 days :-) The one thing I have wanted the most and the longest is a way to add new functions without having to rebuild and look after a custom version of make. Essentially this should allow

Re: Patch to allow make to load plugins that add new functions.

@gnu.org [mailto:bug-make-bounces+libarria=nvidia@gnu.org] On Behalf Of Tim Murphy Sent: Thursday, April 05, 2012 2:51 AM To: bug-make@gnu.org Subject: Patch to allow make to load plugins that add new functions. Hi, I am between jobs which made me realise that I am absolutely free

Re: Patch to allow make to load plugins that add new functions.

Hi, On 5 April 2012 23:12, Paul Smith psm...@gnu.org wrote: Hi Tim; Before going too much further note that I've got a semi-implemented load operator in my source already, which fulfills a similar function except in a less sophisticated way: it just calls a function in the loaded object

Re: Patch to allow make to load plugins that add new functions.

critical to do so - hence adding syntax is quite possible. I was trying to avoid doing that because it's always so controversial but since Paul already has a plan for syntax... Regards, Tim -David Boyce On Thu, Apr 5, 2012 at 1:12 PM, Tim Murphy tnmur...@gmail.com wrote: Hi, On 5 April 2012 20

Re: Dump the database to a makefile and invoke make on the dumped makefile.

and an ideal make tool would somehow help one to deal with that without one having to maintain different and very complicated makefiles for each situation. Regards, Tim On 26 February 2012 19:51, Paul Smith psm...@gnu.org wrote: On Sat, 2012-02-18 at 18:46 +, Tim Murphy wrote: The option

Re: [bug #35485] New $(.MFDIR) built-in variable

Hi, I know this is tangential, but: MAKEFILE_LIST itself is a problem for non-recursive builds because it gets very big if you have a lot of include statements (as opposed to a gigantic single makefile file). Regards, Tim On 8 February 2012 18:30, David Boyce invalid.nore...@gnu.org wrote:

Re: [bug #35485] New $(.MFDIR) built-in variable

, David Boyce david.s.bo...@gmail.com wrote: On Thu, Feb 9, 2012 at 5:33 AM, Tim Murphy tnmur...@gmail.com wrote: Hi, I know this is tangential, but: MAKEFILE_LIST itself is a problem for non-recursive builds because it gets very big if you have a lot of include statements (as opposed

Re: 'withfile' function implementation

Just a quick comment on this. I looked at the implementation and it seems like a different name would suit this function - e.g. writefile. It basically writes text from it's arguments out to a file. The idea of a function called withfile seems hard to actually implement - I'm not sure how one

Re: make error

...@gnu.org wrote: On Wed, 2011-10-05 at 16:07 +0100, Tim Murphy wrote: Your makefile is trying to execure a directory rather than a program. Hah!  I didn't even notice it was a directory.  Good catch. I'm having a really bad week. -- You could help some brave and decent people to have access

Re: make error

Your makefile is trying to execure a directory rather than a program. Cheers, Tim On 5 October 2011 15:48, Carolina Carneiro caro...@astro.ufrj.br wrote: Hi, I'm trying to use make to compile the drivers of a program I have to use, called MOCASSIN. But when I type make mocassin, this error

Re: New Feature Submission for GNU Make

I would rather see a heck of a lot of new functions actually. I am really fed up with some of the limitations of gnu make as it is that might be solved very easily with even 1 or two well chosen new ones. Perhaps a warning when one redefines an internal function might be the way to avoid

  1   2   >