New feature: Post-requisites

[thutt]

Alejandro Colomar writes:
 > Hi,
 >
 > I'd like to suggest a new feature: post-requisites.
 >
 > As the word suggests, as pre-requisites are satisfied before a given
 > target, post-requisites would be satisfied _after_ a given target.
 >
 > Why would someone ever need that in a Makefile:
 >
 > In an install target for a library, you may want to run ldconfig(8)
 > after any install targets have executed.
 >
 > In an install target for the linux man-pages, you may want to run
 > mandb(8)  after any pages have been installed in the system.
 >
 > The proposed syntax would be similar to that of order only
 > prerequisites, but using '>' instead of '|':
 >
 > [
 > [...]
 >
 > $(DESTDIR)$(man3dir)/foo.3: man3/foo.3 | $(DESTDIR)$(man3dir) > update-mandb
 >  $(info INSTALL  $@)
 >  @$(INSTALL_DATA) -T $< $@
 >
 > $(DESTDIR)$(man3dir)/bar.3: man3/bar.3 | $(DESTDIR)$(man3dir) > update-mandb
 >  $(info INSTALL  $@)
 >  @$(INSTALL_DATA) -T $< $@
 >
 > .PHONY: update-mandb
 > update-mandb:
 >  $(info MANDB)
 >  @mandb
 >
 > .PHONY: install
 > install: $(DESTDIR)$(man3dir)/foo.3 $(DESTDIR)$(man3dir)/bar.3
 > ]
 >
 > So that `make install` would install foo.3 and bar.3, and after all of
 > the pages have been installed, mandb(8) would be run.
 > And `make /usr/local/share/man/man3/foo.3` would install foo.3, and
 > after it, it would run mandb(8).
 >
 > Does that make sense to you?


In your example, wouldn't the following accomplish the same thing?


update-mandb:  $(DESTDIR)$(man3dir)/foo.3 $(DESTDIR)$(man3dir)/bar.3

Re: Idea: Add .COMMANDCHANGE and .CACHE

[thutt]

Edward Welbourne writes:
 > On Mon, Jun 10, 2019 at 5:14 PM David A. Wheeler  
 > wrote:
 > >>> Using a lot of some_fragment.mk files gets you *closer*, but it's not
 > >>> the same thing.  My proposed .COMMANDCHANGE depends on
 > >>> the *expanded* set of commands, not the original commands.
 > >>> That way, if you change a value (say CCFLAGS) the set of commands
 > >>> is considered *different* and will be re-run.
 > 
 > On Tue, 11 Jun 2019 04:14:04 -0800, Britton Kerin  
 > wrote:
 > >> I know, but you can put whatever you want in included files, including
 > >> variables.  You can't capture eg vars from the environment but if you're 
 > >> doing
 > >> much of that you're missing half the  point of make anyway (recipe 
 > >> capture).
 > 
 > David A. Wheeler (11 June 2019 15:19)
 > > As you noted, in many ways that's misusing make.
 > 
 > A fairly common change between runs of make is to select between
 > optimised (release) builds and variously instrumented builds (debug,
 > coverage, ...).  While I always prefer to do out-of-source builds and
 > have a separate build tree for each flavour of build, building in the
 > source tree is a conventional and widespread practice.  One then has to
 > make clean when switching between flavours.  Having make recognise when
 > the command it would run is different from what it last ran, as another
 > reason to run the command (just like a changed prerequisite), would save
 > that need to make clean (which it's all too easy to forget).

 Considering that many build systems created with Make do not properly
 perform incremental builds (because all the necessary rules are not
 written, or are written incorrectly), it's also a way to trivially
 make a build that is mysteriously broken because one or more files
 will not be properly rebuilt.

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[Newbie] Getting involved

[thutt]

Måns Ansgariusson writes:
 > Hello!
 >
 > I have an idea of some features I'd like to see in make. I'm no expert at all
 > regarding make so I hope I don't reinvent the wheel or come with to stupid
 > ideas.
 > I'd be happy to implement it but I'm not sure if these are desirable
 > features or where to start.
 >
 > Proposed features:
 > 1. Saving build information

 

 Make is stateless by design.

 It is possible to do what you want with Gnu Make, already, though.
 See 'Rebuilding when CPPFLAGS changes' in "Gnu Make Unleashed".


 >
 > 2. Command execution should inherit from the previous shells in its 
 > dependency
 > graph

 


 This can be done with 'pattern-specific' and 'target-specific'
 variables.


 > 3. Target a specific subsystem
 > I'm a really lazy bastard and this might be going against the original 
 > idea
 > of make but here it goes. What if we could target just one subsystem 
 > with a
 > specific rule given an input parameter to make.
 > An example:
 > 
 > CFLAGS = -Wall -Wextra -std=c99 -Wno-format -Wno-parentheses
 > 
 > debug: CFLAGS += -DDEBUG -g
 > debug: all
 > .
 > make debug --src=src/subsystem
 > .
 > Given I have a large software project and I know I have a bug in
 > a specific subsystem I would like to be able to add the debug options 
 > only
 > to that specific build system. Again this is perhaps more of a software
 > solution that the software project by itself take care of but I'm just
 > throwing the idea out there.
 >

 This is accomplished by making a target that will build just 'src/subsystem'.

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

about EOS make error

[thutt]

ying ye writes:
 > Hi 
 >   
 > The following error occurred when I executed "./eosio_build.sh".
 > 

 There is no actionable information in your message.  You have not
 stated what the problem is, or what you are trying to accomplish, or
 how this is an issue with Gnu Make (this mailing list is for
 discussing Gnu Make).



 > 该程序为 x86_64-pc-linux-gnu 编译
 > 报告错误到 
 > Error compiling MongoDB C driver.
 > 
 > Exiting now.
 > 

 It looks more like an issue in building MongoDB.  I think you will
 find more help in MongoDB mailing lists.

-- 
Does a photon exist before someone sees it?


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #53201] Target runs incorrect command when shebang line exceeds kernel limit

[thutt]

Casey McGinty writes:
 > Follow-up Comment #2, bug #53201 (project make):
 > 
 > See http://man7.org/linux/man-pages/man2/execve.2.html
 > 
 > *A maximum line length of 127 characters is allowed for the first line in an
 > interpreter script.*

 I think this is referring to the '#!' line of a script, not internal
 kernel limits.  This limitation should not affect Gnu Make recipes.

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Seeing below build issue for cat9k

[thutt]

Amruta Bhat (amrbhat) writes:
 > Hi all,
 > I am receiving below error when I try to build cat9k image. 
 > 
 > ' '!' -f /users/amrbhat/.no_makej -a '!' -f 
 > /nobackup/amrbhat/polaris_3_1/vob/
 > ios/sys/.no_makej ']'
 > + echo '/auto/binos-tools/bin/makej - No STEP supported MakeJ found -  using
 > SRG makej wrapper'
 > /auto/binos-tools/bin/makej - No STEP supported MakeJ found -  using SRG 
 > makej
 > wrapper
 > + exec /bin/nice -n1 /auto/binos-tools/makej/make_wrapper-lnx -f /nobackup/
 > amrbhat/polaris_3_1/binos/build/make-lib/mcp_ios_precommit.mk -w 
 > --include-dir=
 > /nobackup/amrbhat/polaris_3_1/binos/build/make-lib cat9k_super
 > connect() failed: Connection refused
 > Warning: scheduler not available, falling back to -j4
 > /router/bin/make-4.2.1-p0: unrecognized option '--jobserver-fds=3,6'
 > Usage: make-4.2.1-p0 [options] [target] ...
 > 
 > Trying " mcp_ios_precommit cat9k_super” to build.
 > 
 > 
 > Anyone can help me on this.?

 This is a mailing list for reporting defects in Gnu Make.

 Please work with your internal tech leads, or the project team of the
 software you are trying to build.

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: gmake-4.2.1 ignores assignment of ARCH on FreeBSD

[thutt]

Yuri writes:
 > On 12/26/17 19:38, Paul Smith wrote:
 > > If the BSD Ports framework is setting
 > > some variables "as if" they were provided on the command line,
 > 
 > 
 > But there is no such thing as "providing something as if on the command 
 > line".
 > 

 Paul just explained that there is a way to make a variable seem like
 it's set on the command line, when in fact it's not.

 Here's a simple Makefile:

   install:
  @echo $(alpha)
  @echo $(origin alpha)


 From the shell:

   export MAKEFLAGS="alpha=not-set-on-command-bline"
   make

 not-set-on-command-bline
 command line

 It's not a normal way of using Make, but it does deserve to be
 examined.

-- 
Festivus time!

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Converting make rules into other file formats

[thutt]

SF Markus Elfring writes:
 > > A Makefile is basically a human-readable text file with instructions
 > > on how to create executables with a compiler for example.
 >
 > How often do you look for a more visual representation of this content?
 >
 >
 > > It has pretty much nothing to do with creating graphics.
 >
 > I got an other opinion.
 >
 > * Do you care to display constructed directed acyclic graphs
 >   by other tools?
 >
 > * Are you interested in further improvements for data export variants?

 I use graphviz.  But I work on a tool that generates the Makefiles,
 and I can have it output a graph description alongside the Makefiles.

 If you have onlky Makefiles, I can envision a few ways to generate a
 graph.  This is a bit manual, but you could use order-only
 prerequisites to dump out the dependency tree to different 'node'
 files (consider '-j'), and post process all the node files into a
 bigger graph.

all:alpha beta

ALPHA_PREREQS = alpha.c alpha.h
BETA_PREREQS =  beta.c beta.h

alpha:  $(ALPHA_PREREQS) | alpha.node

beta:   $(BETA_PREREQS) | beta.node

alpha.node: $(ALPHA_PREREQS)
echo "$@ depends on $^" >$@

beta.node:  $(BETA_PREREQS)
echo "$@ depends on $^" >$@


 You may be able to get some different inspiration from "Gnu Make
 Unleashed" section in the section called 'Making and XML bill of
 materials in GNU Make'.

 Essentially, you need to run Make because of the runtime processing
 of the variables defined in the Makefiles, or you've got to interpose
 yourself before Make and know the dependency graph already.

thutt
--
The gym does not appreciate 'Row Row Row Your Boat' while one is rowing.

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

TP-LINK Archer T2UH HELP

[thutt]

jason reynolds writes:
 >Can you help me? I am trying to setup my wifi adapter and I keep
 >getting an error.

 This mailing list is for discussions about Gnu Make.
 You are asking a specific question about how to build firmware for
 your router.  You will need to find a forum where your router and its
 firmware are discussed to obtain an answer.
-- 


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #51591] Typographical error in manual

[thutt]

anonymous writes:
 > URL:
 >   
 > 
 >  Summary: Typographical error in manual
 >  Project: make
 > Submitted by: None
 > Submitted on: Thu 27 Jul 2017 02:58:59 PM UTC
 > Severity: 3 - Normal
 >   Item Group: Documentation
 >   Status: None
 >  Privacy: Public
 >  Assigned to: None
 >  Open/Closed: Open
 >  Discussion Lock: Any
 >Component Version: None
 > Operating System: Any
 >Fixed Release: None
 >Triage Status: None
 > 
 > ___
 > 
 > Details:
 > 
 > Hello,
 > 
 > Please check the section at the URL here:
 > http://www.gnu.org/software/make/manual/make.html#Cleanup
 > 
 > In the following example:
 > 
 > .PHONY : clean
 > clean :
 > -rm edit $(objects)
 > 
 > This should read:
 > 
 > .PHONY : clean
 > clean :
 > rm edit $(objects)

 This is not a typo.  The '-' prefix instructs make to ignore the
 return code from the command.  This allows 'make clean' to be
 successfully executed when there are no files to delete in the
 directory.

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Q: On Windows why not ignore CRLF?

[thutt]

Edward Welbourne writes:

 > The remaining question is whether it's *possible* for a text-mode
 > file handle on MS to still have a '\r' just before its '\n' in a
 > line, presumably due to a CRCRLF mess in the raw file.

 Yes, it most certainly is possible.  Translation only occurs on
 '\r\n'.

   Hello\r\r\n.

 Will end up as:

   Hello\r\n

 after being read.  The translation doesn't back up and reprocess:.

   Hello\r\n

 into

   Hello\n

 The '\n' conversion to '\r\n' on output is transparent, and putting
 '\r\n' in the output stream will end up with '\r\r\n' in the file.


--
What books will be in the Trump Presidential Library?

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Q: On Windows why not ignore CRLF?

[thutt]

Eli Zaretskii writes:
 > > From: Paul Smith 
 > > Date: Wed, 31 May 2017 19:48:57 -0400
 > >
 > > I'm working on ensuring that the test suite works on Windows
 >
 > That's great news, thanks!
 >
 > >   #if !defined(WINDOWS32) && !defined(__MSDOS__) && !defined(__EMX__)
 > > /* Check to see if the line was really ended with CRLF; if so 
 > > ignore
 > >the CR.  */
 > > if ((p - start) > 1 && p[-2] == '\r')
 > >   {
 > > --p;
 > > memmove (p-1, p, strlen (p) + 1);
 > >   }
 > >   #endif
 > >
 > > I'm not sure about this implementation (performance-wise) but leaving
 > > that aside, I don't understand why this code is ifdef'd out on Windows.
 >
 > Well, it's your code, or so it seems ;-)  And it was always ifdef'ed
 > away on those platforms, since the day it was committed back in 1999
 > (see commit 7052a57).
 >
 > > I mean, CRLF is more prevalent on Windows so why wouldn't we have this
 > > there?
 > >
 > > Is the idea that on Windows we want to preserve the CRLF, for some
 > > reason?  I'm not sure I see the point in doing that when we're parsing
 > > the makefile; I mean we'd throw away all the newlines on UNIX, so why
 > > would we preserve the CRLF on Windows?
 >
 > I think Ray is right: the CRLF combination simply cannot happen on
 > those platforms, because Make there uses text-mode reads, so the CR
 > characters are simply gone by the time we get here.

 I concur that the code is disabled on Windows due to text mode
 stripping away the '\r' and leaving only '\n' in the input stream.

 I surmise it's enabled on non-Windows builds to allow them to work
 wtih Makefiles created on a Windows machine.

thutt
--
What books will be in the Trump Presidential Library?

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

errors in "make"

[thutt]

wu writes:
 > Dear gnu group,
 >
 > I work on Ubuntu. I tried to install a program, but there are some errors 
 > when
 > I do "make". my make version is as follows:
 >
 > "GNU Make 4.1
 > Built for x86_64-pc-linux-gnu
 > Copyright (C) 1988-2014 Free Software Foundation, Inc.
 > License GPLv3+: GNU GPL version 3 or later 
 > This is free software: you are free to change and redistribute it.
 > There is NO WARRANTY, to the extent permitted by law."
 >
 > my gcc version is :
 >
 > "gcc (Ubuntu 6.2.0-5ubuntu12) 6.2.0 20161005
 > Copyright (C) 2016 Free Software Foundation, Inc.
 > This is free software; see the source for copying conditions.  There is NO
 > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE."
 >
 > the software reports the following errors:
 >
 > "pregraph_sparse_63mer.v1.0.3 objects generated.
 > SOAPdenovo-63mer objects generated.
 > /usr/bin/ld: ./sparsePregraph/inc/libbam.a(bam_aux.o): relocation 
 > R_X86_64_32S
 > against `.rodata' can not be used when making a shared object; recompile with
 > -fPIC

 

 > Do you have any ideal for this error?


 Those cretainly don't look like errors 'in make'.

 They look like errors from the tools that the Makefile is executing.
 I suggest you speak with your tech leads, or with the people who
 wrote the software and ask them how to build it.


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

unable to query Makefile

[thutt]

Roopashree, B.S writes:
 >Hi Team,
 > 
 >Recently am hitting this error with no change in the Makefile.
 > 
 >Can someone help on this as it is stopping my progress.
 > 
 >Below is the error:
 > 
 >/pkg/qct/software/gnu/make/4.0/bin/make: invalid option -- 'u'
 > 
 > 
 >LOGFILE:
 >/prj/qct/verif/fvcad/bangalore/scratch01/workspaces/broopash/ubus_examp
 >le/ubus_uvm_qbar_new/qvmr/broopash/simulate_only_issue/qvmr/broopash/si
 >mland/ubus.sl/ubus/0.test_read_modify_write/latest/session.log
 > 
 > 
 >Let me know if you need anything on the same.

 This mailing list is for the discussion of Gnu Make develpment and
 programming errors.  It looks like you a have a problem in using
 Make.  It's recommended that you discuss these problems with your
 tech leads, or with the people who created the original Makefiles.

 That notwithstanding, you've provided no actionable information in
 your report.  I suggest you narrow the problem down before speaking
 with your tech leads.


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Make all throws alot of errors

[thutt]

Sherine Davis writes:
 > I keep getting alot of errors for make all on every package that i try to
 > install.
 > Please help

 >
 >
 > $make all
 > make  all-recursive
 > make[1]: Entering directory '/home/Sherine Davis/libmtp-1.1.12/libmtp-1.1.12'
 > Making all in src
 > make[2]: Entering directory '/home/Sherine Davis/libmtp-1.1.12/libmtp-1.1.12/
 > src'
 > /bin/sh ../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I..
 >  -IC:/msys64/mingw64/include/libusb-1.0 -g -O2 -Wall -Wmissing-prototypes -MT
 > libmtp_la-libmtp.lo -MD -MP -MF .deps/libmtp_la-libmtp.Tpo -c -o
 > libmtp_la-libmtp.lo `test -f 'libmtp.c' || echo './'`libmtp.c
 > libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -IC:/msys64/mingw64/include/
 > libusb-1.0 -g -O2 -Wall -Wmissing-prototypes -MT libmtp_la-libmtp.lo -MD -MP
 > -MF .deps/libmtp_la-libmtp.Tpo -c libmtp.c  -DDLL_EXPORT -DPIC -o .libs/
 > libmtp_la-libmtp.o
 > libmtp.c: In function 'LIBMTP_Open_Raw_Device_Uncached':
 > libmtp.c:1885:17: error: 'PTPParams {aka struct _PTPParams}' has no member
 > named 'cd_locale_to_ucs2'
 >current_params->cd_locale_to_ucs2 = iconv_open("UCS-2LE", "UTF-8");

 


 This mailing list is for the discussion of Gnu Make.  Your question
 is related to one or more projects that use Gnu Make.  This mailing
 list is not the right place to ask for help regarding errors produced
 by compilers when using Gnu Make.

 Please direct your questions to the appropriate project's mailing
 list.

--
https://www.youtube.com/watch?v=U9t-slLl30E


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Parallel builds across makefiles

[thutt]

sgardell writes:
 > We are using a standard distro of gmake 4.1 on RH 6.4.
 >
 > We have a fairly well structured makefile system that leverages the ACE make
 > framework. A linear build (-j1) is about 3 hours. Running a parallel build
 > that builds leaf nodes (libraries) in parallel is about 1 hour. So far so
 > good.
 >
 > But when I try to build across makefiles in parallel then I see two
 > different things:
 >1) If I turn on any sort of output sync it gets dramatically slower.
 > Sometimes slower than our -j1 time!
 >2) Even with output sync turned completely off there is no meaningful
 > improvement over a parallel build of just the leaves.
 >
 > I am reasonably certain that I am actually seeing parallel build behavior
 > since I had to fix a handful of additional dependency issues to get it to
 > build. Also reasonably certain that the build is not doing different things
 > since the count of compiler invocations matches. Looking at 'top' during the
 > "highly parallelized" runs shows the system essentially idle.
 >

 Is there a question or problem that you're posing?

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

RE: Permission Denied error while killing Gmake on Windows

[thutt]

Anuj Shroff writes:
 > Hello Mr Hutt
 >
 > The reproduction steps you have mentioned for the issue are precisely what 
 > we are doing.
 >
 > I am monitoring killing gmake using ProcessExplorer. I can see that
 > the processes are killed as soon as we issue CTRL_C. However, it is
 > a bit difficult to deduce whether the subprocesses are killed
 > before the files are removed or not. I am not sure how to do such
 > fine-grained debugging.  Would you happen to have a suggestion for
 > this. I will be happy to try it out.
 >
 > Also, we tried to track the obj files with ProcMon. Running ProcMon
 > in the background slows the gmake process significantly, due to
 > which we cannot reproduce the issue.
 >
 > Please let me know if you have any pointers.

 I don't think you can guarantee that the asynchronous subprocesses
 are killed off at the same time as the parent.

 Rather than trying to prove this using Make, I'd suggest writing a
 bespoke program that spawns asynchronous processes, which create
 files with known pathnames and leave them open.  Kill the parent and
 try to remove the files that the subordinate process created.

--
For more information, dial 411.


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

RE: Permission Denied error while killing Gmake on Windows

[thutt]

Anuj Shroff writes:
 > Hello Eli
 >
 > Please find a small snippet of process name from ProcessExplorer
 > attached. It shows the compiler names and the process name.
 >
 > While experiment a bit more with this we found an interesting
 > workaround which seems to have given some promising results.
 >
 > We tweaked the gmake source code so that when we are deleting
 > targets while handling fatal signals (like SIGINT or SIGTERM), if
 > we encounter an error we sleep for 3 seconds and retry.
 >
 > In our case we are getting the Permission Denied error while
 > deleting the obj files. When we used this new gmake, it gave us
 > good results and we are no longer seeing the "deleting files:
 > Permission Denied" error. Also the corrupt obj files (due to the
 > interrupt) are cleaned up properly.
 >
 > We would like to know your opinion on this.

 If I understand things correctly, you are doing this:

   o Starting gmake
   o 
   o Send Ctrl-C to gmake
   o gmake removes object files when it received Ctrl-C.

 On Windows, you will get a 'Permission Denied' when attempting to
 delete a file if another process has it open.

 Have all the subprocesses of gmake been fully killed before
 attempting to remove files?


--
For more information, dial 411.


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: I found a bug with Makefile

[thutt]

Albert Le Batteux writes:
 > Sorry for all the missing information.
 > so :
 > make --version : GNU Make 3.81  This program built for 
 > i386-apple-darwin11.3.0
 > OSX el capitan v 10.11.3
 > 
 > i sent you my project in a zip file.
 > 

 > How it's work :
 > (with the error)
 > > make exe
 > > move a little (with arrow, select some element with  spacebar)
 > > press ctrl + z to send a SIGTSTP signal
 > > back in the shell press fg to come back.
 > > ctrl + z again and you will see, when you'll fg back
 > you will have a error in terminal.c with   if (tcsetattr(0, TCSADRAIN, term) 
 > <
 > 0)

 I don't think this is an error with Make.  This is probably an error
 in your code, based on the description and the fact that terminal.c
 is in your project.
-- 
Cole's Law: Thinly sliced cabbage.

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

I found a bug with Makefile

[thutt]

Albert Le Batteux writes:
 > Hello !
 > I have really no idea about who i am talking !
 >
 > I am a french student programmer, and making a school project with termcaps
 > named ft_select (you can find many of this project on github)
 > It's a termcaps introdution by creating a small selecting item menu.
 >
 > I always lunch my program with a Makefile rule like `make exe` (it's easier 
 > and
 > faster)
 > but it's create that error on tcsetattr() !
 >
 >
 > `Interrupted system call` on errno from `tcsetattr()`
 >
 >
 > Maybe start a program with make create a fake environment.. ? i don't know ..
 >
 > i put my question on StackOverflow : http://stackoverflow.com/questions/
 > 34992713/launch-command-with-makefile?noredirect=1#comment57723426_34992713
 >
 > By curiosity, if you can explain me why ?
 >
 > Cordially,
 >

 Please provide the Makefile, the host OS you are using, and the
 version of Make you are using (make --version).

--
Cole's Law: Thinly sliced cabbage.

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Adding line numbers to output for "No rule to make target"

[thutt]

Jonny Grant writes:
 > >   If you do it that way, now you've got two different formats for the
 > >   same message.  This can be confusing to users, and certainly
 > >   complicates factors if there is software sitting on top of Make and
 > >   operating on the messages (continuous integration / automatic failure
 > >   triage).
 >
 > CI uses program return codes in my experience.
 > EXIT_SUCCESS is 0

 On failure, CI may operate on the output text to determine the locus
 of the actual failure, and automatically file defects.

 >
 > >   Consider the following other special cases:
 > >
 > > o Gnu Make has $(eval), and it's possible to generate rules that
 > >   don't correspond to actual Makefile lines.
 >
 > I thought the message only related to targets.
 > Do you mean if targets are generated by $(eval) ?

 Yes.

 >
 > > o What if there are multiple targets that refer to 'test.o'?
 > >   Should all be reported, or just the one that failed?
 >
 > Often compilation only reports the first occurrence of the error. Make
 > could behave in a similar way. A more advanced solution would
 > report more.

 Sure, it's software; it could do lots of things.  The point I'm
 trying to get across is that requesting a feature in a mature product
 means that many scenarios must be explored, including not breaking
 existing uses.


--
There's not enough Naugahyde in the world today.

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Adding line numbers to output for "No rule to make target"

[thutt]

Jonny Grant writes:
 > 
 > 
 > On 25/11/15 13:59, th...@vmware.com wrote:
 > > Jonny Grant writes:
 > >   > Hello
 > >   >
 > >   > Could line numbers be added to output for the case where it says "No
 > >   > rule to make target" please?
 > >   >
 > >   > Example below. GNU Make 4.1
 > >   >
 > >   > I'm not on this list, so please include my email address is any
 > >   > replies Regards, Jonny
 > >
 > >   >
 > >   >
 > >   > makefile.mak
 > >   >
 > >   > %.o : %.d
 > >   >
 > >   > all: test.o
 > >   > echo processing
 > >   >
 > >   >
 > >   > ^Sorry TAB has been lost by my email client
 > >   >
 > >   > $ make
 > >   > make: *** No rule to make target 'test.o', needed by 'all'.  Stop.
 > >   >
 > >   >
 > >   > Could line number (4) be added to the message?
 > >   >
 > >   > eg
 > >   > $ make
 > >   > make: *** makefile.mak:4 No rule to make target 'test.o', needed by
 > >   > 'all'.  Stop.
 > >
 > >   What should be output if the following is typed?
 > >
 > > make gungla
 > >
 > 
 > Perhaps just the regular because its not got a specific line number:
 > 
 > $ make gungla
 > make: *** No rule to make target 'gungla'. Stop.
 > 
 > 
 > What do think?

 My point was that it's not so simple.

 If you do it that way, now you've got two different formats for the
 same message.  This can be confusing to users, and certainly
 complicates factors if there is software sitting on top of Make and
 operating on the messages (continuous integration / automatic failure
 triage).

 Consider the following other special cases:

   o Gnu Make has $(eval), and it's possible to generate rules that
 don't correspond to actual Makefile lines.

   o What if there are multiple targets that refer to 'test.o'?
 Should all be reported, or just the one that failed?

 (Is the recipe that cannot be built important, or is the use of
 'test.o' important?)

-- 
There's not enough Naugahyde in the world today.

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Adding line numbers to output for "No rule to make target"

[thutt]

Jonny Grant writes:
 > Hello
 >
 > Could line numbers be added to output for the case where it says "No
 > rule to make target" please?
 >
 > Example below. GNU Make 4.1
 >
 > I'm not on this list, so please include my email address is any
 > replies Regards, Jonny

 >
 >
 > makefile.mak
 >
 > %.o : %.d
 >
 > all: test.o
 > echo processing
 >
 >
 > ^Sorry TAB has been lost by my email client
 >
 > $ make
 > make: *** No rule to make target 'test.o', needed by 'all'.  Stop.
 >
 >
 > Could line number (4) be added to the message?
 >
 > eg
 > $ make
 > make: *** makefile.mak:4 No rule to make target 'test.o', needed by
 > 'all'.  Stop.

 What should be output if the following is typed?

   make gungla


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Makefile line number bug?

[thutt]

Jonny Grant writes:
 > Hello
 > Is this a bug? line numbers are output as (2), but actually they are
 > different. Note that also the "Hello" is output in the wrong order.. I
 > presume this may be the OS rather than GNU Make.
 > 
 > Please keep my email address in replies as I am not a member of this list.
 > 
 > Regards, Jonny
 > 
 > $ make -f makefile.mak
 > makefile.mak:2: One
 > makefile.mak:2: Two
 > makefile.mak:2: Three
 > Hello
 > 
 > $ make --version
 > GNU Make 4.1
 > Built for i686-pc-cygwin
 > Copyright (C) 1988-2014 Free Software Foundation, Inc.
 > License GPLv3+: GNU GPL version 3 or later 
 > This is free software: you are free to change and redistribute it.
 > There is NO WARRANTY, to the extent permitted by law.
 > 
 > 
 > 
 > makefile.mak (not sure if the TABs have been lost)
 > all:
 > @echo Hello
 > $(warning One)
 > $(warning Two)
 > $(warning Three)
 > 

 Tabs have been lost.

 If the 'warning' lines are at the beginning of the line, make behaves
 with the proper line numbers.

 If there are tabs before each 'warning', then you get the result you
 posted.

 A curious result, to be sure.


-- 
p4 help commandments

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make