[sphinx-users] Code blocks and latexpdf
I recently upgraded to Sphinx v5.3.0, and it looks like something has
changed in the latexpdf generation. I have an rst file with the following C
code snippet:
:code:`"%zu\n"`
Previously, this worked fine in producing latex output. However, with
v5.3.0, I get the following error on "make latexpdf":
! Text line contains an invalid character.
l.14023 \sphinxcode{\sphinxupquote{"\%zu^^@
n"}} is a suitable format %
So, the \n in the code block was converted into "^@n" in the .tex file,
which throws an error with latex. What is the proper way to put in the "\n"
in a code block and have it work with latex?
--
You received this message because you are subscribed to the Google Groups
"sphinx-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sphinx-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sphinx-users/1b99bbca-9722-49a1-831c-d7c92fea11ccn%40googlegroups.com.
Re: determining whether -jN was used
On Thu, 2024-05-23 at 11:34 -0400, DSB wrote: > "To access the pipe you must parse the 'MAKEFLAGS' variable and look > for the argument string '--jobserver-auth=R,W'" I don't have time to test this right now but I think in 4.2 you have to look at the shell variable, not the makefile variable. E.g. $(info $(shell echo $$MAKEFLAGS))
Re: [bug #65759] handling of "-" and "--" on command line
On Mon, 2024-05-20 at 07:25 +0200, Henrik Carlqvist wrote: > On Sun, 19 May 2024 18:02:45 -0400 (EDT) > > Many programs use a single dash to mean "read from stdin" but make > > doesn't > > do this. > > Yes, it does: > > -8< > nazgul:/tmp> make -f - Yes, if you give -f (which means read from a makefile) then use "-" as the filename it will read from stdin. But, if you just use "make -" (without -f) then it won't read from stdin.
Re: Treat "Circular dependency...dropped" as a hard error instead?
On Mon, 2024-05-13 at 22:05 -0400, Dmitry Goncharov wrote: > On Wed, May 8, 2024 at 2:04 PM JZB wrote: > > > > I have a GNU make-based build system wherein I would like for > > any/all > > GNU make-detected circular dependencies to be treated as a hard > > error, > > i.e., fail [immediately], rather than a "dropped and we go on > > without > > it..." situation. > > > > Is there a way to do this already? > > I think, that's a good idea. > i added two patches which implement this ability. > You'll need to wait for make with the patches to be released or apply > the patches yourself. Thanks Dmitry that's exactly what I was going to suggest, I just have an extremely frazzled week here.
Re: what is autotools, what is gnulib
On Thu, 2024-05-09 at 23:16 +0200, Bruno Haible wrote: > Paul Smith wrote: > > If all we cared about was portability to GNU systems we could do > > away with 99% of autotools and gnulib; basically everything except > > portability between older and newer versions of glibc-based > > systems. > > While it is true that Autotools and Gnulib care a lot about > portability, they are also significantly useful for packages that > target *only* glibc-based systems. I did say it was still useful in the context of supporting historical versions of glibc-based systems. In addition to that of course there are differences related to hardware architectures which I meant to include but forgot. By "only caring about GNU systems" I mean: no libc except glibc, no compiler except GCC / binutils, no shell except bash, no make except GNU Make, no shell utils other than GNU shellutils, no awk except Gawk, no sed except GNU sed, etc. etc. And since there are only a few kernels that are supported by glibc, there are few kernel-level differences that need to be considered. Many of the extra capabilities provided by gnulib could simply be subsumed by glibc, either directly or as an extra library: there's no need to provide these with each software package if we only support GNU systems; we can just assume they are always present. Clearly glibc needs a POSIX interface so that non-GNU software can be ported to it, but GNU software doesn't need to limit itself to that interface: it can rely on all extended GNU behavior without checking if it exists. This is a purely academic discussion as I definitely do not suggest this is appropriate (in fact my original email argued against it). For example, abandoning small targeted libc's that already exist, like musl, and precluding support for any future system unless it first ported ALL the above software, would definitely be A Bad Thing, both for GNU in particular and for Free Software in general. > In particular, the following are significantly useful in this > setting: With respect to automake, if we could require that nothing but GNU Make was used, IMO automake per se would not be needed and its entire implementation could be provided as a boilerplate makefile (or possibly two) that would be included by the package makefile, without requiring Makefile.am or Makefile.in. Autoconf would either generate a makefile setting appropriate variables which would be included, or the boilerplate makefile could digest the contents of config.status at runtime and set make variables appropriately. This boilerplate makefile could also always be present as a standard part of a GNU system and would not need to be included in source packages. Again, I do not suggest this.
Re: Unportable makefile example in "Makefile Convention" section
On Mon, 2024-05-06 at 13:47 -0400, Alfred M. Szmidt wrote: > I was referring to the GNU Coding Standard manual > > It is portable across GNU systems, other systems are not a high > priority. The mission of the GNU project is to develop the GNU > system after all, and the GNU Coding Standards document that. Sorry Alfred but I can't agree with your statements here. The entire reason that the FSF and GNU project expend so much energy and time on things like autotools and gnulib, is exactly so that GNU projects can, with relatively little effort, be portable to non-GNU systems. We absolutely DO care, a lot, about this and the GNU coding standards are intended to reinforce this portability, not just hardware portability. If all we cared about was portability to GNU systems we could do away with 99% of autotools and gnulib; basically everything except portability between older and newer versions of glibc-based systems.
Re: Unportable makefile example in "Makefile Convention" section
On Tue, 2024-05-07 at 00:04 +0800, Kang-Che Sung wrote: > Sorry, but I think you missed this: I was referring to the GNU Coding > Standard manual, not GNU Make manual. > > Specifically this page: > https://www.gnu.org/prep/standards/html_node/Makefile-Basics.html Sorry this was sorted into my pile of GNU Make issues; I didn't notice it wasn't directed at the GNU Make mailing lists. -- Paul D. Smith Find some GNU Make tips at: https://www.gnu.org http://make.mad-scientist.net "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
Re: Unportable makefile example in "Makefile Convention" section
On Mon, 2024-05-06 at 23:27 +0800, Kang-Che Sung wrote: > So why is `$<` even suggested here in the example when it's > unportable? It's not the goal, or desire, of the GNU Make manual to use only portable constructs in its examples. The GNU Make manual exists to document using GNU Make and all its examples should work correctly with GNU Make. In some places in the GNU Make manual we do point out specific things which may be non-portable, but that's just an informational courtesy for the reader. Anyone who wants to actually write portable makefiles and not use any non-portable features, would be better off following a different document such as the POSIX specification for make, than using the GNU Make manual. Cheers! -- Paul D. Smith Find some GNU Make tips at: https://www.gnu.org http://make.mad-scientist.net "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
[Bug 2062042] Re: "No valid sources.list entry found" and "An upgrade might not succeed" when running "sudo do-dist-upgrade -d" on Ubuntu 23.10
This fixed the problem. Thanks! Although, I wonder if this will affect others who try to upgrade to 24.04 when it releases tomorrow? That's part of the reason that I went ahead and posted the bug rather than just waiting for the release date. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2062042 Title: "No valid sources.list entry found" and "An upgrade might not succeed" when running "sudo do-dist-upgrade -d" on Ubuntu 23.10 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/2062042/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: GNU Make 4.4.1 fails in a spectacular fashion on NetBSD 10.0 AMD64
On Fri, 2024-04-19 at 14:38 -0400, Dmitry Goncharov wrote: > On Fri, Apr 19, 2024 at 1:42 PM Paul Smith wrote: > > The main advantages to alloca are twofold: > > > > 1) efficiency for small local buffers, which GNU Make uses a lot. > > > > 2) simplification of the code because you don't have to track this > > memory and ensure it's freed regardless of how the function > > returns. > > Dennis, do you see an alternative that is at least equally efficient, > simple and portable? One alternative that is equally efficient and > simple is variable length arrays. However, there is a question about > portability of vla vs alloca. VLAs are strictly less powerful than alloca because alloca() is scoped to the function, while VLAs are scoped to the enclosing block. That is a serious flaw in VLAs and means that it is impossible for them to replace alloca() in many simple, obvious situations. In addition, while alloca() is best implemented by the compiler it IS possible to provide a standards-conforming implementation of them (which is less performant than a compiler-provided alloca(), but which works) which means that alloca() is more portable than VLAs, which will cause compiler errors in any compiler that doesn't support them. So, I have zero interest in VLAs. In my opinion they were a mistake from the first and should never have been implemented or standardized. I did share this opinion and provided examples of how limiting and limited they were back when they were being considered for standardization but, well, it didn't matter.
Re: GNU Make 4.4.1 fails in a spectacular fashion on NetBSD 10.0 AMD64
On Fri, 2024-04-19 at 13:15 -0400, Dennis Clarke wrote: > Yep. The calls to alloca() seem to be all over the place in the code > base and I can not figure out why anyone would want a non-portable > and non-standard thing like that but here we are. alloca() has been used in the GNU Make code ever since the earliest days in the 1980's. Some of these concerns in the man page are only partly relevant: GNU Make comes with its own working implementation of alloca() which it will use if the compiler doesn't support it. This is tested regularly so we know it works. Unfortunately in your situation the configure script detected that your system DID support alloca, so we didn't use our implementation. It seems wrong that NetBSD provides a broken implementation of alloca(). IMO it should either provide a working implementation, or not provide an implementation at all (so that programs like GNU Make will decide to use an alternative). The configure script always assumes that if the system provides a feature, it's the best one to use. Second, GNU Make uses a wrapper around all memory allocation which immediately exits if we fail to obtain memory (e.g., malloc returns NULL) so it's not that much different if we run out of stack space: you'll still crash just in a different way. The main advantages to alloca are twofold: 1) efficiency for small local buffers, which GNU Make uses a lot. 2) simplification of the code because you don't have to track this memory and ensure it's freed regardless of how the function returns. Unfortunately C doesn't have any sort of RAII or destructor facility. I am in no way condoning the use of alloca in general or suggesting that new programs should continue to use it. I would not use the source code for GNU Make as an example of good coding practices in 2024, in any way (except maybe some smaller, more modern parts). But the above is why it works the way it does, and why changing it is not as trivial as "cut and paste".
Re: GNU Make 4.4.1 fails in a spectacular fashion on NetBSD 10.0 AMD64
On Fri, 2024-04-19 at 09:54 -0400, Dennis Clarke via Bug reports and discussion for GNU make wrote: > Where does one even begin to discover where something ( everything? ) > went so horribly wrong? The very first thing you should try is re-configuring GNU Make without any special flags (unset CFLAGS) and re-run configure from scratch and see if that build works better. As far as I can tell the problem is because you're including this: -fno-builtin in your CFLAGS. I'm not sure why you want to do that, but I recommend removing that, at least. I don't actually know exactly why that causes a problem but it's completely clear from the test results that the problems you're having are due to bad memory which means I agree with you it's due to this alloca mismatch/issue. I can't say why the problem happens: either GCC's handling of -fno-builtin has an issue or else the configure script's detecting of the situation is not working correctly. > /opt/bw/build/make-4.4.1_NetBSD_10.0_amd64.001/src/ar.c:315: warning: > Warning: reference to the libc supplied alloca(3); this most likely > will not work. Please use the compiler provided version of alloca(3), > by supplying the appropriate compiler flags (e.g. -std=gnu99). Clearly this warning is not fully grokking your situation. The most likely reason for this mismatch in general is someone adding -std=c99 which of course disables extensions like alloca so that's what the warning says, but it's not looking at what you ACTUALLY have set on the compiler command line. You do have -std=gnu99 but this warning didn't notice that you also have -fno-builtin and that's the real reason for this issue.
[Bug 2062042] Re: "No valid sources.list entry found" and "An upgrade might not succeed" when running "sudo do-dist-upgrade -d" on Ubuntu 23.10
No problem. Let me know if you need anything else. ** Attachment added: "sources.list.d.tar.gz" https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/2062042/+attachment/5766910/+files/sources.list.d.tar.gz -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2062042 Title: "No valid sources.list entry found" and "An upgrade might not succeed" when running "sudo do-dist-upgrade -d" on Ubuntu 23.10 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/2062042/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2062042] [NEW] "No valid sources.list entry found" and "An upgrade might not succeed" when running "sudo do-dist-upgrade -d" on Ubuntu 23.10
Public bug reported: I receive the message following message when performing a "sudo do- release-upgrade -d" on both my Ubuntu 23.10 system(s): Fetched 23.8 kB in 0s (0 B/s) Reading package lists... Done Building dependency tree... Done Reading state information... Done Fetched 0 B in 0s (0 B/s) Updating repository information No valid sources.list entry found While scanning your repository information no entry about mantic could be found. An upgrade might not succeed. Do you want to continue anyway? Continue [yN] The message "An upgrade might not succeed" is of concern, so obviously I can't proceed with the upgrade. My sources.list.d directory looks like this: cvpsmith@tars:/etc/apt/sources.list.d$ ls cubic-wizard-ubuntu-release-mantic.sources slack.list google-chrome.sources spotify.sources jonaski-ubuntu-strawberry-lunar.sources teams.list mozillateam-ubuntu-ppa-mantic.sources ubuntu.sources nvhpc.list And here are the contents of "ubuntu.sources": Types: deb URIs: http://archive.ubuntu.com/ubuntu Suites: mantic mantic-updates mantic-security mantic-backports Components: main restricted universe multiverse Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg As is evident, removing "vscode.list" from sources.list.d/ has no effect. lsb_release -rd No LSB modules are available. Description:Ubuntu 23.10 Release:23.10 ** Affects: ubuntu-release-upgrader (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2062042 Title: "No valid sources.list entry found" and "An upgrade might not succeed" when running "sudo do-dist-upgrade -d" on Ubuntu 23.10 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/2062042/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Touch-packages] [Bug 2047447] Re: No valid source.list found while upgrading from mantic to noble
Will do, thanks! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to python-apt in Ubuntu. https://bugs.launchpad.net/bugs/2047447 Title: No valid source.list found while upgrading from mantic to noble Status in python-apt package in Ubuntu: Fix Released Status in ubuntu-release-upgrader package in Ubuntu: Invalid Status in python-apt source package in Mantic: Confirmed Status in ubuntu-release-upgrader source package in Mantic: Invalid Bug description: Checking package manager Reading package lists... Done Building dependency tree... Done Reading state information... Done Hit http://fr.archive.ubuntu.com/ubuntu mantic InRelease Hit http://fr.archive.ubuntu.com/ubuntu mantic-updates InRelease Hit http://fr.archive.ubuntu.com/ubuntu mantic-security InRelease Hit http://fr.archive.ubuntu.com/ubuntu mantic-backports InRelease Hit https://packages.gitlab.com/gitlab/gitlab-ce/ubuntu lunar InRelease Fetched 0 B in 0s (0 B/s) Reading package lists... Done Building dependency tree... Done Reading state information... Done Checking for installed snaps Calculating snap size requirements Updating repository information No valid sources.list entry found While scanning your repository information no entry about mantic could be found. An upgrade might not succeed. Do you want to continue anyway? Continue [yN] To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/2047447/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Bug 2047447] Re: No valid source.list found while upgrading from mantic to noble
Will do, thanks! -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2047447 Title: No valid source.list found while upgrading from mantic to noble To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/2047447/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2047447] Re: No valid source.list found while upgrading from mantic to noble
I can confirm that I have the same issue on two separate 23.10-based systems, but removing vscode.list from /etc/apt/sources.list.d/ has no effect. I get the following warning with "sudo do-release-upgrade -d": Updating repository information No valid sources.list entry found While scanning your repository information no entry about mantic could be found. An upgrade might not succeed. Do you want to continue anyway? Obviously, I don't want to attempt the upgrade if it may bork the system. Any ideas on when this might see a fix? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2047447 Title: No valid source.list found while upgrading from mantic to noble To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/2047447/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Touch-packages] [Bug 2047447] Re: No valid source.list found while upgrading from mantic to noble
I can confirm that I have the same issue on two separate 23.10-based systems, but removing vscode.list from /etc/apt/sources.list.d/ has no effect. I get the following warning with "sudo do-release-upgrade -d": Updating repository information No valid sources.list entry found While scanning your repository information no entry about mantic could be found. An upgrade might not succeed. Do you want to continue anyway? Obviously, I don't want to attempt the upgrade if it may bork the system. Any ideas on when this might see a fix? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to python-apt in Ubuntu. https://bugs.launchpad.net/bugs/2047447 Title: No valid source.list found while upgrading from mantic to noble Status in python-apt package in Ubuntu: Fix Released Status in ubuntu-release-upgrader package in Ubuntu: Invalid Status in python-apt source package in Mantic: Confirmed Status in ubuntu-release-upgrader source package in Mantic: Invalid Bug description: Checking package manager Reading package lists... Done Building dependency tree... Done Reading state information... Done Hit http://fr.archive.ubuntu.com/ubuntu mantic InRelease Hit http://fr.archive.ubuntu.com/ubuntu mantic-updates InRelease Hit http://fr.archive.ubuntu.com/ubuntu mantic-security InRelease Hit http://fr.archive.ubuntu.com/ubuntu mantic-backports InRelease Hit https://packages.gitlab.com/gitlab/gitlab-ce/ubuntu lunar InRelease Fetched 0 B in 0s (0 B/s) Reading package lists... Done Building dependency tree... Done Reading state information... Done Checking for installed snaps Calculating snap size requirements Updating repository information No valid sources.list entry found While scanning your repository information no entry about mantic could be found. An upgrade might not succeed. Do you want to continue anyway? Continue [yN] To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/2047447/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
Re: A question about submitting a new source code file
On Sun, 2024-04-07 at 09:30 -0400, Dmitry Goncharov wrote: > Good morning, Paul. > > Thanks for the explanation. > > On Sun, Apr 7, 2024 at 8:08 AM Paul Smith wrote: > > In short, if you create a new file and assign it to the FSF then > > you can still do whatever you want with that file, including even > > use a completely proprietary license for it. > > i am intending to include that file to a library of mine which is > released under the bsd license. Usually, souch source code file would > contain something like > /* > * Copyright (c) 2017 Dmitry Goncharov > * > * Distributed under the BSD License. > * (See accompanying file COPYING). > */ > > Do i understand it correctly, that in my copy of this new file that > is assigned to the FSF, i'll remove the copyright part and the header > becomes > /* > * Distributed under the BSD License. > * (See accompanying file COPYING). > */ > and whoever is using that library can keep using it under the BSD > license? I don't believe that's how it works. Instead, the version of this file that is provided with GNU Make will be provided under the GPLv3 and with an FSF copyright, like the rest of the source code. But you are free to also use/provide that same content via some other method (for example in another program) under the license of your choice (such as BSD), under the clause in the license agreement I quoted. So, as Basile suggests, the version of this source file that we commit to the GNU Make repo would have the standard copyright/license header that all other source files have, plus if you like an extra note saying it was contributed by you and, again if you like, a note about where it came from/what package it was originally developed for: this is not covered by the guidelines and I have no objection to it. Cheers! -- Paul D. Smith Find some GNU Make tips at: https://www.gnu.org http://make.mad-scientist.net "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
Re: Issue with intprops-internal.h / GCC 8.3
On Sat, 2024-03-30 at 02:17 +0100, Bruno Haible wrote: > The problem with your git repository setup (maintMakefile line 32, > that enables -Werror by default) is that in practice, it's not > only developers who build from git repositories. Namely, many people > whose habits have been shaped by GitHub will look for the git > repository before looking for a release tarball. Well, they are in for some hardship. Building GNU Make from Git requires a significant number of tools to be installed, including automake, autoconf, gettext, texinfo, gnulib, perl 5 (if tests are run), and probably some other things I've forgotten. I do not ever check in any generated files, at all (except, I guess, the gnulib bootstrap script which is generated by gnulib) so all these tools need to be installed by the user to build from Git. Hence we can assume that anyone building GNU Make from Git is sufficiently knowledgeable abut Free Software build environments that they can obtain and configure all the above tools, at sufficient versions (I tend to require the latest versions, pretty quickly after release). However, I'll reconsider whether to preserve -Werror by default, and at least document the proper way to disable it in the README.git file which should be used by those building GNU Make from Git workspaces. What I'd really prefer to do is provide a "nightly source tarball" somewhere which contains the latest Git code, already configured, for those who want to try it. But I don't have a simple way to do that with the current GNU infrastructure AFAIK. It seems like there's little appetite for deleting content from alpha.gnu.org, or creating ephemeral content there. -- Paul D. Smith Find some GNU Make tips at: https://www.gnu.org http://make.mad-scientist.net "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
Re: Please check about the GIT problem.
On Sat, 2024-04-06 at 16:50 +0900, 12zz12 wrote: > I'm not used to it, so I run the translator. It's no different, but > when I used Ubuntu 22 version and put in the installation command to > install the git and executed it, it shows that this happens as > follows. And you don't have to cover the user name in the path. This > is because I changed it to a different account name. What I'm > currently using seems to be a problem with personally installing the > git in Korea. You seem to be having a problem building the Git project. This mailing list is for help and bugs in the GNU Make project. Nothing in your message indicates any kind of bug or issue with GNU Make: it is working properly. Please direct your question about problems building Git, to the Git project mailing lists instead. They should be able to help you! But, based on the error you received: > /bin/sh: 1: asciidoc: not found I would say you need to install the asciidoc program on your system in order to build the Git documentation. Cheers! -- Paul D. Smith Find some GNU Make tips at: https://www.gnu.org http://make.mad-scientist.net "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
Re: variable reassign value in same makefile
On Thu, 2024-04-04 at 07:10 +, anand akhare wrote: > I am looking for confirmation if this is expected behavior. Target > specific variables will not have visibility outside of its recipe. I > am using VAR variable across makefile. Please see David's answer, here: https://lists.gnu.org/archive/html/help-make/2024-04/msg1.html in case you are not subscribed to the mailing list. -- Paul D. Smith Find some GNU Make tips at: https://www.gnu.org http://make.mad-scientist.net "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
Re: A question about submitting a new source code file
On Wed, 2024-04-03 at 09:33 -0400, Dmitry Goncharov wrote: > Paul, i'd like to contribute another bugfix which involves a brand > new source code file. i will assign the ownership to fsf, if needed. > However, i'd like to be able to use that source file in my other > projects, which are not gpl. i have seen other gnu projects including > public domain code. What is your take on this? Do you think a file > can be included in make, if i made it public domain? Hi Dmitry: I apologize for the delay in responding: I was scuba diving in Honduras this past week. I'm not sure I recall which paperwork you used to assign to the FSF, but it doesn't really matter. All paperwork I'm aware of provides that anything you assign to the FSF, the FSF then grants you a complete license to that code to do whatever you like with (insofar as it's yours: if you just modify already-existing GPL'd code created by someone else you don't get a license for that). In short, if you create a new file and assign it to the FSF then you can still do whatever you want with that file, including even use a completely proprietary license for it. Here is the relevant bit of the agreement which I believe is the one you signed: > (d) FSF agrees to grant back to Developer, and does hereby grant, > non-exclusive, royalty-free and non-cancellable rights to use the > Works (i.e., Developer's changes and/or enhancements, not the Program > that they enhance), as Developer sees fit; this grant back does not > limit FSF's rights and public rights acquired through this agreement. -- Paul D. Smith Find some GNU Make tips at: https://www.gnu.org http://make.mad-scientist.net "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
Re: After having updated nvidia drivers, cannot start obs
On Sat, Mar 30, 2024 at 4:43 PM wrote: > > Hi. > > On Sun, 24 Mar 2024 22:19:51 +0000 Paul Smith wrote: > > > This error began after: > > > Packages Altered: > ... > > @rpmfusion-nonfree-updates > > Upgraded akmod-nvidia-3:550.54.14-2.fc39.x86_64 > > @@System > ... > > @rpmfusion-nonfree-updates > > Upgraded xorg-x11-drv-nvidia-3:550.54.14-1.fc39.x86_64 > > @@System > > Have you wait for akmods to compile the nvidia kernel modules before > rebooting ? > > "lsmod | grep nvidia" should list the nvidia module (and some others) > loaded. Example: > > lsmod | grep nvidia > nvidia_drm 81920 5 > nvidia_modeset 1511424 3 nvidia_drm > nvidia_uvm 2760704 0 > nvidia 40706048 99 nvidia_uvm,nvidia_modeset > video 77824 2 dell_wmi,nvidia_modeset > > "modinfo nvidia | grep version" should give the same version as > xorg-x11-drv-nvidia, ie: 550.54.14 > > If this is not the case, try to rebuild the kernel modules with: > > sudo akmods --rebuild I thank all who have answered! By following Francis's advice of sudo akmods --rebuild I was able to fix the problem. Paul -- ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Issue with intprops-internal.h / GCC 8.3
I have a bug report for a compiler error in GNU Make, using intprops-internal.h, on Debian 10 with GCC 8.3: https://savannah.gnu.org/bugs/?65537 This is with gnulib stable-202401 current Git HEAD. Thoughts? Maybe I just have to disable this warning? Note, I already do not enable -Werror etc. by default in source distributions so this wouldn't be seen by a user of an official release, but this user is building straight from the Git repository and I usually enable all warnings + -Werror for these builds.
Re: Pattern rules without recipe
On Fri, 2023-06-09 at 09:39 +0200, Frank Heckenbach wrote: > Another thing that surprised me which I assume is working as > designed, but I think should be spelled out clearer in the manual: I added a paragraph about this to the main page describing pattern rules. Thanks for the note! -- Paul D. Smith Find some GNU Make tips at: https://www.gnu.org http://make.mad-scientist.net "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
Re: [PATCH] Fix jobserver does not work on OS/2
On Wed, 2023-12-13 at 20:05 +0900, KO Myung-Hun wrote: > mkfifo() on OS/2 is a dummy, even it returns a wrong value on error. > > Do not use it on OS/2. I applied this change, thanks! -- Paul D. Smith Find some GNU Make tips at: https://www.gnu.org http://make.mad-scientist.net "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
Re: [PATCH] Fix integer overflow test in parse_int
On Sun, 2024-01-07 at 16:09 -0800, Paul Eggert wrote: > * src/arscan.c (parse_int): Use intprops.h macros rather than trying > to detect integer overflow by hand, and doing it incorrectly. > Here is an example of why the old code was incorrect. > If val == 3689348814741910323, base == 10, *ptr == '0', UINTMAX_WIDTH > == 64, > then (val * base) + (*ptr - '0') yields 18446744073709551614, > which is greater than val even though overflow has occurred. > Fortunately this bug could not be triggered on GNU/Linux hosts, > although it may be possible on platforms (if any) where struct ar_hdr > has members so large that they can represent integers that do not fit > int uintmax_t. I applied this, thanks for the patch Paul! -- Paul D. Smith Find some GNU Make tips at: https://www.gnu.org http://make.mad-scientist.net "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
Re: Issue with 'src/variable.c'
On Wed, 2024-02-07 at 13:35 +0100, Gisle Vanem wrote: > Since the commit: > https://git.savannah.gnu.org/cgit/make.git/commit/src/variable.c?id=ec348f51d0240ebc64d11c77c461e89c4a8dfed7 > > src/variable.c doesn't compile: > variable.c(1642): error C2065: 'specificity': undeclared > identifier > variable.c(1658): error C2065: 'specificity': undeclared > identifier > > Should it be: The proposed patch is actually backwards (it should be NULL if the scope is global, not the current_variable_set_list). However I applied a fix, thanks for the note! -- Paul D. Smith Find some GNU Make tips at: https://www.gnu.org http://make.mad-scientist.net "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
Re: [PATCH] Update test documentation to use correct path flag
On Tue, 2024-02-20 at 01:07 -0800, Marco Sirabella wrote: > See: 5058a94e I updated this section of the tests/README, thanks for the note! -- Paul D. Smith Find some GNU Make tips at: https://www.gnu.org http://make.mad-scientist.net "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
Re: [PATCH] Check bare-path comparison between archived path & target
On Sun, 2024-02-25 at 16:46 -0800, Marco Sirabella wrote: > When archive files are created with gnu ar's P flag the parent paths > of saved files aren't stripped off. This is helpful when you're > adding multiple files to an archive with the same stem but different > parent paths. I applied this change, but slightly differently. Thanks for the note! -- Paul D. Smith Find some GNU Make tips at: https://www.gnu.org http://make.mad-scientist.net "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
Re: confusing language in manual re GNUMAKEFLAGS
On Tue, 2024-03-05 at 08:54 -0500, DSB wrote: > I think this little nit should be cleared up. In one place the manual > says: > > ... after parsing GNUMAKEFLAGS GNU make sets this variable to the > empty string ... > > But in another place it says: > > GNU make never sets this variable itself. > > The meaning is clear (to me) but the language is not well formed. I tried to clarify this; thanks for the note! -- Paul D. Smith Find some GNU Make tips at: https://www.gnu.org http://make.mad-scientist.net "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
Re: suggestion regarding names of temp files
On Mon, 2024-03-18 at 13:04 -0400, DSB wrote: > Minor suggestion: In 9.7 Temporary Files the manual says "These files > must not be disturbed while make is running" but it doesn't say what > "these files" look like. Assuming the names have some pattern, would > it make sense to be more specific and say something like "do not > remove temp files matching gnumake.*"? I added some info about this to the GNU Make manual, thanks for the note! -- Paul D. Smith Find some GNU Make tips at: https://www.gnu.org http://make.mad-scientist.net "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
Re: Dropping "call" operator?
On Tue, 2024-03-26 at 10:15 -0700, Kaz Kylheku wrote: > However, I'm noticing that expansion preserves the semantic > boundaries, which is important. If we have $(x) that expands > to a,b, then we /can/ invoke $(call $(x),c,d). The delimiting > of argument material must be happening prior to expansions > (at least in the abstract). Yes, this is true for most parts of the parser and is a common and long-standing way to avoid issues with special characters and parsing. There's no chance of this ever changing. Make (almost) always does word separation BEFORE it does expansion. I actually can't think of a place where this is not true but it's possible I'm forgetting something.
Re: Variables and $(shell ...)
On Mon, 2024-03-25 at 23:35 +0100, Tomas Volf wrote: > I (think I) can just swap the order and do `CC=gcc make' in order to > work around the issue (is that correct assumption?), but would like > to understand why it behaves like this. Dmitry explained that in versions of GNU Make prior to 4.4, none of the extra variables in the makefile were passed to the $(shell ...) function. Using "CC=cc make" may work, or not, depending on your makefile. Variables assigned in the makefile take precedence over variables inherited from the environment, while variables added to the command line as arguments take precedence over variables defined in the makefile. So if your makefile says: CC = gcc then running "make CC=cc" WILL override it, but "CC=cc make" WILL NOT override it. If your makefile says: CC ?= gcc then both will work. A more flexible, although slightly annoying, option is to set the variable(s) in the $(shell ...) code directly: yyy = $(shell foo='$(foo)' env | grep ^foo=) If there are a lot of them you can of course put the variables you care about in a variable then expand them, like: VARS := foo CC ENVSET = $(foreach V,$(VARS),$V='$($V)') yyy = $(shell $(ENVSET) env | grep ^foo=) (I should point out that this change in GNU Make 4.4 has the potential to cause your makefile to take exponentially more time to run if you are not careful; in particular you really want to be using simple expansion (:=) with the $(shell ...) function).
Re: Dropping "call" operator?
On Mon, 2024-03-25 at 18:47 -0700, Kaz Kylheku wrote: > > I have considered doing this, but only AFTER it becomes an error > > (not just a warning) to create a make variable with whitespace in > > the name. > > Could you elaborate? How recent of a gmake do we need for this > diagnostic? The current Git version (next release) will warn about variables created with spaces in the name, regardless of how they get there: $ cat Makefile define a b c $(info hello) endef $ ./make Makefile:1: warning: invalid variable name 'a b c' make: *** No targets. Stop. This can be turned into an error via: $ ./make --warn=error -f /tmp/x1.mk Makefile:1: *** invalid variable name 'a b c'. Stop. There's nothing wrong with creating a variable name containing a comma and I don't anticipate making this illegal.
After having updated nvidia drivers, cannot start obs
Dear All, I am getting the following error message when trying to start OBS Studio: info: Initializing OpenGL... libEGL warning: DRI2: failed to authenticate MESA: error: ZINK: failed to choose pdev libEGL warning: egl: failed to create dri2 screen error: Unable to create EGL context: EGL_BAD_ATTRIBUTE error: Failed to create context! error: device_create (GL) failed error: Failed to initialize video. Your GPU may not be supported, or your graphics drivers may need to be updated. This error began after: Packages Altered: Upgrade mplayer-1.5.1-0.12.20240317svn.fc39.x86_64 @rpmfusion-free-updates Upgraded mplayer-1.5.1-0.8.20230811svn.fc39.x86_64 @@System Upgrade mplayer-common-1.5.1-0.12.20240317svn.fc39.x86_64 @rpmfusion-free-updates Upgraded mplayer-common-1.5.1-0.8.20230811svn.fc39.x86_64@@System Upgrade akmod-nvidia-3:550.67-1.fc39.x86_64 @rpmfusion-nonfree-updates Upgraded akmod-nvidia-3:550.54.14-2.fc39.x86_64 @@System Upgrade nvidia-modprobe-3:550.67-1.fc39.x86_64 @rpmfusion-nonfree-updates Upgraded nvidia-modprobe-3:550.54.14-1.fc39.x86_64 @@System Upgrade nvidia-persistenced-3:550.67-1.fc39.x86_64 @rpmfusion-nonfree-updates Upgraded nvidia-persistenced-3:550.54.14-1.fc39.x86_64 @@System Upgrade nvidia-settings-3:550.67-1.fc39.x86_64 @rpmfusion-nonfree-updates Upgraded nvidia-settings-3:550.54.14-1.fc39.x86_64 @@System Upgrade xorg-x11-drv-nvidia-3:550.67-1.fc39.x86_64 @rpmfusion-nonfree-updates Upgraded xorg-x11-drv-nvidia-3:550.54.14-1.fc39.x86_64 @@System Upgrade xorg-x11-drv-nvidia-cuda-3:550.67-1.fc39.x86_64 @rpmfusion-nonfree-updates Upgraded xorg-x11-drv-nvidia-cuda-3:550.54.14-1.fc39.x86_64 @@System Upgrade xorg-x11-drv-nvidia-cuda-libs-3:550.67-1.fc39.x86_64 @rpmfusion-nonfree-updates Upgraded xorg-x11-drv-nvidia-cuda-libs-3:550.54.14-1.fc39.x86_64 @@System Upgrade xorg-x11-drv-nvidia-kmodsrc-3:550.67-1.fc39.x86_64 @rpmfusion-nonfree-updates Upgraded xorg-x11-drv-nvidia-kmodsrc-3:550.54.14-1.fc39.x86_64 @@System Upgrade xorg-x11-drv-nvidia-libs-3:550.67-1.fc39.x86_64 @rpmfusion-nonfree-updates Upgraded xorg-x11-drv-nvidia-libs-3:550.54.14-1.fc39.x86_64 @@System Upgrade xorg-x11-drv-nvidia-power-3:550.67-1.fc39.x86_64 @rpmfusion-nonfree-updates Upgraded xorg-x11-drv-nvidia-power-3:550.54.14-1.fc39.x86_64 @@System Could you please help me? Thanks in advance, Paul -- ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Catching errors in pipes
On Tue, 2023-12-05 at 13:43 +0100, Sébastien Hinderer wrote: > Is there a recommended way to catch errors in pipelines of coommands > that are used in recipes, please? This isn't a GNU Make issue. It's a shell programming issue. Make just invokes the shell and waits for it to exit, then looks at the exit code. If you want the behavior of pipefail you have to get your recipe to implement that behavior: there's nothing make can do about it. I recommend checking on StackOverflow or similar places looking for idioms that will support this for POSIX shells. Just to note, starting with the next POSIX version, set -o pipefail is part of the standard so you can expect it to start appearing in POSIX- conforming shells that don't already support it. Of course, that doesn't help if you must support older shells. -- Paul D. Smith Find some GNU Make tips at: https://www.gnu.org http://make.mad-scientist.net "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
Re: Dropping "call" operator?
On Wed, 2023-12-27 at 21:45 -0800, Kaz Kylheku wrote: > What would be wrong with allowing the $(call ...) operator to be > elided? > > Instead $(call macro,a,b,c), why can't we have $(macro a,b,c), if > macro doesn't shadow a built-in function? > > When there are no arguments, we cal invoke it as $(macro), but when > there are arguments $(call ...) must be used. > > The presence of arguments can be used to deduce that a macro call > with arguments is to take place. I have considered doing this, but only AFTER it becomes an error (not just a warning) to create a make variable with whitespace in the name. -- Paul D. Smith Find some GNU Make tips at: https://www.gnu.org http://make.mad-scientist.net "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
Re: TESTs fail features/output-sync and features/parallelism on Linux 4.4.194 armv7l
On Tue, 2024-02-27 at 03:22 -0500, Dennis Clarke via Bug reports and discussion for GNU make wrote: > *** Testing FAILED! Details: > makeerror-4.4.1-armv7l-unknown-linux-gnueabihf-izkr.tar.gz > *** Please report to Apologies for the delay in replying. When filing a bug report for failed regression tests please also attach the tarball generated (see note above). If you prefer you can send it directly to me rather than to the mailing list. Thanks! -- Paul D. Smith Find some GNU Make tips at: https://www.gnu.org http://make.mad-scientist.net "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
Re: bisecting gnu make
I'm sorry I didn't think of this before, but another option would be to use the build.sh bootstrapping script, which we provide for situations where you want to build GNU Make on systems where there isn't already a make instance available. This doesn't run make and doesn't require a configure, it just uses a simple build.cfg file which is generated by configure but you can see it's trivial and just leave it alone. As for bisecting across compile errors, compile errors that are committed are exceedingly rare but it happens: sometimes things work on my system but not on other systems. It is something your bisecting code will have to take into account, and just move past to the next commit. There's a "git bisect skip" command for this. On Mon, 2024-03-18 at 12:58 -0400, DSB wrote: > Unfortunately it looks like I won't be able to get this solved. I was > hoping to, and even thinking of contributing some README-type > documentation on how to do it, but I just couldn't get it to work and > we ended up solving the problem another way so the impetus is gone. I > didn't keep track of all the details but in case anyone's curious > here are a few: > > - The first bisection (between tags 4.3 and 4.4.1) happened to land > on 6f8da5f4b86a679143d6f6b99e8cfcc1f19a0593 which says "Don't use > STRING_SIZE_TUPLE in mempcpy. If mempcpy() is a macro then > STRING_SIZE_TUPLE won't compile". And sure enough the compile fails > on my system. The fix is simple but having a local change breaks the > subsequent bisection with various complications. > > - README.git says that autoconf 2.69 is required which is exactly > what I have. But at some point in the bisection it aborts saying 2.71 > is required. I have no idea how that could happen but it did, > repeatedly. > > - When rolling time backward using GNU make, or really with any > timestamp-based build tool, it's necessary to do clean builds. But > make clean seems to remove src/mkcustom.h which then breaks further > builds. Dmitry's makefile has a workaround for this but stashing and > reusing a generated file seems unsafe. > > - Sometimes the generated binary dumped core. I'm sure this could be > diagnosed, and if git HEAD core-dumped locally it would be worth my > looking into it, but I can't justify debugging a core dump in a > hacked environment at some random hash from the past. So at this > point I dropped the project. > > Dmitry: I did make some changes to your makefile so I attach a > renamed version in case you want to take any of them. The one I > remember is to cause "make --version" to show the git hash it was > built from which I think might even be worth keeping in the > production version though not in the first line. If the idea is kept, > though, it shouldn't be done by hacking config.h as I did but > presumably with a -D flag. Also, I had to add -std=c99 and some -W > flags to keep the compiler happy. And I removed the -MMD etc since I > was doing clean builds every time anyway. > > David > > On Tue, Mar 12, 2024 at 11:21 AM David Boyce > > wrote: > > > Thank you both for the replies. I've had little time to get back to > > this > > and little success when I tried but it's too early to draw any > > conclusions. > > I'll update on progress when I get back to it. > > > > Paul, I didn't know "make make" was an option but it doesn't seem > > to help. > > Actually I think there's a bit of a bug. Starting from latest git > > on > > CentOS7.6 here's what I see: > > > > ./bootstrap && ./configure && make make > > ... > > make: *** No rule to make target 'lib/libgnu.a', needed by 'make'. > > Stop. > > > > A regular "make" completes after which "make make" works. > > > > David > > > > On Sat, Mar 9, 2024 at 12:16 PM Dmitry Goncharov > > > > wrote: > > > > > On Fri, Mar 8, 2024 at 9:32 AM DSB wrote: > > > > Is there a scripted way to > > > > reliably build make at each bisection point (assuming 4.3 as > > > > the > > > minimum)? > > > > > > There is definitely a scripted way to do this. > > > i use this small makefile (see in the attachment) instead of the > > > automake generated one. > > > This makefile builds make from all .c files located in src/ and > > > lib/. > > > Keep your src/ and lib/ free of stray .c files. > > > This makefile also correctly handles removals of header files and > > > all > > > other known .d file necessities. > > > > > > To use it > > > 1. Create a subdirectory in your make source code directory. Step > > > to > > > this newly created subdirectory. > > > 2. Run ../configure. This needs to be done once to generate > > > config.h. > > > 3. Run make -f ../test.mk. > > > 4. Checkout another commit and run make -f ../test.mk. No need to > > > run > > > configure or bootstrap again. > > > > > > Here is a sample bash session. > > > > > > dgoncharov@opti:~/src/gmake/make $ mkdir t64 > > > dgoncharov@opti:~/src/gmake/make $ cd t64 > > > dgoncharov@opti:~/src/gmake/make/t64 $ ../configure --without- > > > guile > > >
[Isbg] What are your thoughts on the pricing of the Fear of God Essentials Hoodie? Do you think it's justified for the quality and brand?
An Essentials Hoodie is incredibly versatile, making it a valuable addition to any closet. Whether you're going for a casual look or aiming for a more put-together ensemble, the hoodie can seamlessly transition between various styles. Pair it with jeans for a laid-back vibe, or layer it under a blazer for a smart-casual twist. The versatility of an Essentials Hoodie allows you to create multiple outfits with just one piece of clothing brand is https://fearofgod.uk/ ___ Isbg mailing list -- isbg@python.org To unsubscribe send an email to isbg-le...@python.org https://mail.python.org/mailman3/lists/isbg.python.org/ Member address: arch...@mail-archive.com
Re: multi-threaded compiling
On Tue, 2024-03-12 at 13:37 +0100, Mischa Baars wrote: > > I'd still like to hear why you aren't simply using "make -j". > > That's because I don't want to define static compile and link targets > for every new project I start. The Makefile in question contains only > a few lines of code and some environment variables, but works on > every new project as long as you follow certain guidelines regarding > the directory structure. It scans, compiles and links on the fly. I don't find this argument compelling. It's relatively straightforward to create a makefile environment that "works on every new project as long as you follow certain guidelines regarding the directory structure" while still using parallel builds, that will "scan, compile, and link" on the fly, using things like the wildcard function, pattern rules, etc. You are merely trading a bit of extra complexity in your makefile for a whole lot of complexity and tricky hacking in bash, as can be seen by following this thread. But if you prefer to re-invent make's parallel build capabilities in bash, certainly that's your prerogative.
Re: multi-threaded compiling
On Tue, 2024-03-12 at 13:37 +0100, Mischa Baars wrote: > > I'd still like to hear why you aren't simply using "make -j". > > That's because I don't want to define static compile and link targets > for every new project I start. The Makefile in question contains only > a few lines of code and some environment variables, but works on > every new project as long as you follow certain guidelines regarding > the directory structure. It scans, compiles and links on the fly. I don't find this argument compelling. It's relatively straightforward to create a makefile environment that "works on every new project as long as you follow certain guidelines regarding the directory structure" while still using parallel builds, that will "scan, compile, and link" on the fly, using things like the wildcard function, pattern rules, etc. You are merely trading a bit of extra complexity in your makefile for a whole lot of complexity and tricky hacking in bash, as can be seen by following this thread. But if you prefer to re-invent make's parallel build capabilities in bash, certainly that's your prerogative.
Re: multi-threaded compiling
On Mon, 2024-03-11 at 15:36 -0400, Greg Wooledge wrote: > You won't be able to take advantage of "wait -n"'s ability to react > to the first job that finishes. You'll end up reaping each job in > the order they started, not the order they finished. It feels to me like you're trying to reproduce make's already-available parallel build support, in a kind of kludgy way with bash. Maybe this is an XY problem and you should step back and describe WHY you're trying to create this behavior using bash instead of just using make's support for parallel jobs. What about make's parallel jobs doesn't meet your requirements (or put another way, what actually are your requirements)?
Re: multi-threaded compiling
On Mon, 2024-03-11 at 15:36 -0400, Greg Wooledge wrote: > You won't be able to take advantage of "wait -n"'s ability to react > to the first job that finishes. You'll end up reaping each job in > the order they started, not the order they finished. It feels to me like you're trying to reproduce make's already-available parallel build support, in a kind of kludgy way with bash. Maybe this is an XY problem and you should step back and describe WHY you're trying to create this behavior using bash instead of just using make's support for parallel jobs. What about make's parallel jobs doesn't meet your requirements (or put another way, what actually are your requirements)?
Re: multi-threaded compiling
On Mon, 2024-03-11 at 19:37 +0100, alex xmb sw ratchev wrote: > /data/data/com.termux/files/usr/bin/sh: 1: Syntax error: Bad for loop > variable This is because of the issue I mentioned in my initial reply. This invocation is using /bin/sh which is a POSIX shell but is not bash; probably it's dash or similar (you are running on Debian or one of the GNU/Linux distros that build on it). If you set "SHELL := /bin/bash" (or whatever the path is for bash on your system) in the makefile you won't see this, I expect.
Re: multi-threaded compiling
On Mon, 2024-03-11 at 19:37 +0100, alex xmb sw ratchev wrote: > /data/data/com.termux/files/usr/bin/sh: 1: Syntax error: Bad for loop > variable This is because of the issue I mentioned in my initial reply. This invocation is using /bin/sh which is a POSIX shell but is not bash; probably it's dash or similar (you are running on Debian or one of the GNU/Linux distros that build on it). If you set "SHELL := /bin/bash" (or whatever the path is for bash on your system) in the makefile you won't see this, I expect.
Re: multi-threaded compiling
On Mon, 2024-03-11 at 18:14 +0100, Mischa Baars wrote: > The actual command invocations (a Makefile, a make.sh script) can be > found in the attachment, as indicated on the first line of the mail. > In the attachment there are two directories, one and two, belonging > to 1) and 2) respectively. That's not what I asked: I asked YOU to run the commands on YOUR system and cut and paste the results of the run into your email message, with an explicit explanation of exactly what is wrong with the results and what you wanted to see instead. What errors did you get? Or what was unexpected about the behavior? I'm not interested in running random scripts on my system that were downloaded from an email, or examining their behavior to make sure they're OK, or setting up a container to run them in, or guessing what you wanted to happen, etc. Or maybe someone else will want to do that work instead. But before putting in more effort on the "misbehaving" makefile, read this part of my response carefully: > But before you do that, be aware that make does NOT invoke /bin/bash > as its shell. It invokes /bin/sh. On some systems /bin/sh is > actually an alias for bash. On other systems it isn't. > > If you want your makefile to always use bash as its shell, you should > add an explicit: > > SHELL := /bin/bash > > to your makefile to force it. Maybe that will solve your problem. > If not we'll need details such as I mention above. and verify in your response you added the suggested line to your makefile and it didn't help (in the situation where the makefile was behaving in an unexpected way).
Re: multi-threaded compiling
On Mon, 2024-03-11 at 18:14 +0100, Mischa Baars wrote: > The actual command invocations (a Makefile, a make.sh script) can be > found in the attachment, as indicated on the first line of the mail. > In the attachment there are two directories, one and two, belonging > to 1) and 2) respectively. That's not what I asked: I asked YOU to run the commands on YOUR system and cut and paste the results of the run into your email message, with an explicit explanation of exactly what is wrong with the results and what you wanted to see instead. What errors did you get? Or what was unexpected about the behavior? I'm not interested in running random scripts on my system that were downloaded from an email, or examining their behavior to make sure they're OK, or setting up a container to run them in, or guessing what you wanted to happen, etc. Or maybe someone else will want to do that work instead. But before putting in more effort on the "misbehaving" makefile, read this part of my response carefully: > But before you do that, be aware that make does NOT invoke /bin/bash > as its shell. It invokes /bin/sh. On some systems /bin/sh is > actually an alias for bash. On other systems it isn't. > > If you want your makefile to always use bash as its shell, you should > add an explicit: > > SHELL := /bin/bash > > to your makefile to force it. Maybe that will solve your problem. > If not we'll need details such as I mention above. and verify in your response you added the suggested line to your makefile and it didn't help (in the situation where the makefile was behaving in an unexpected way).
Re: multi-threaded compiling
On Mon, 2024-03-11 at 09:56 +0100, Mischa Baars wrote: > I've attached the problem. It consists of two parts: > > 1) multi-threaded bash script and / or multi-threaded Makefile > > Running bash script functions as expected, but executing the same > line of code with make and / or the command line, does not function. > Perhaps someone could explain to me why? > > 2) passing a string argument from a bash script and / or Makefile to > the gcc -D option > > Running the makefile functions as expected, but I have not been able > to get similar code to work from a bash script. Can someone please > explain to me what I'm doing wrong? I don't understand the problem. In the third paragraph above you say the bash script works as expected and the makefile doesn't work, but in the last paragraph you say that the makefile works as expected but you can't get it to work in bash. Please provide actual command invocations (cut and pasted) showing the output you received and explaining exactly what is wrong with it. But before you do that, be aware that make does NOT invoke /bin/bash as its shell. It invokes /bin/sh. On some systems /bin/sh is actually an alias for bash. On other systems it isn't. If you want your makefile to always use bash as its shell, you should add an explicit: SHELL := /bin/bash to your makefile to force it. Maybe that will solve your problem. If not we'll need details such as I mention above.
Re: multi-threaded compiling
On Mon, 2024-03-11 at 09:56 +0100, Mischa Baars wrote: > I've attached the problem. It consists of two parts: > > 1) multi-threaded bash script and / or multi-threaded Makefile > > Running bash script functions as expected, but executing the same > line of code with make and / or the command line, does not function. > Perhaps someone could explain to me why? > > 2) passing a string argument from a bash script and / or Makefile to > the gcc -D option > > Running the makefile functions as expected, but I have not been able > to get similar code to work from a bash script. Can someone please > explain to me what I'm doing wrong? I don't understand the problem. In the third paragraph above you say the bash script works as expected and the makefile doesn't work, but in the last paragraph you say that the makefile works as expected but you can't get it to work in bash. Please provide actual command invocations (cut and pasted) showing the output you received and explaining exactly what is wrong with it. But before you do that, be aware that make does NOT invoke /bin/bash as its shell. It invokes /bin/sh. On some systems /bin/sh is actually an alias for bash. On other systems it isn't. If you want your makefile to always use bash as its shell, you should add an explicit: SHELL := /bin/bash to your makefile to force it. Maybe that will solve your problem. If not we'll need details such as I mention above.
Re: bisecting gnu make
On Fri, 2024-03-08 at 07:01 -0500, DSB wrote: > So my question is: has anyone done this before? Is there a scripted > way to reliably build make at each bisection point (assuming 4.3 as > the minimum)? I have never tried to do this, but yes certainly each commit was buildable when it was committed (at least on POSIX-type platforms, I'm not sure every commit built on every platform although they should). Is it really necessary to re-run the entire bootstrap every time? Isn't it sufficient to just re-run "configure && make"? Also, if you don't care about translation files you could just run "make make" instead of rebuilding everything then maybe you wouldn't run into errors regarding the PO files, the texinfo files, etc.
Re: Does gnulib getcwd always allocate if buf is NULL?
On Wed, 2024-03-06 at 19:55 +0100, Reuben Thomas wrote: > In getcwd.c I find the following comment: > > > In GNU, if BUF is NULL, an array is allocated with 'malloc'; the > > array is SIZE bytes long, unless SIZE == 0, in which case it is as > > big as necessary. > > However, as far as I can see from the code, it always allocates if > BUF is NULL. I don't think your observation contradicts the comment...is there more to it? Note the use of a semicolon here which means that the second clause is "separate from" the first clause; this could be rewritten as something like: In GNU, if BUF is NULL, an array is allocated with 'malloc'. If allocated, the allocated array is SIZE bytes long, unless SIZE == 0, in which case it is as big as necessary.
Re: Performance loss when trying to use grouped targets
On Mon, 2024-03-04 at 21:01 -0500, Dmitry Goncharov wrote: > A grouped targets rule like > a.x b.x &: a.q b.q; cp a.q b.q build/ > tells make that a.x depends on a.q and b.q and b.x depends on a.q and > b.q. Which is not "each file depends on its corresponding file". > > The above grouped rule is the same as > a.x: a.q b.q; cp a.q b.q build/ > b.x: a.q b.q; cp a.q b.q build/ (There must be more to this recipe than that since these recipes don't actually build the targets a.x or b.x. I'm assuming you meant each recipe to create both a.x and b.x.) These two formulations are not really the same: grouped targets work differently and can't be replaced with an expanded version. A grouped target: a.x b.x &: a.q b.q ; can only be emulated by something like this: a.x b.x : .sentinel ; .sentinel : a.q b.q ; ; touch $@
Re: Conditional append operator (was: Re: New conditional assignment facility)
On Sun, 2024-02-18 at 22:23 +0100, Jouke Witteveen wrote: > On Sun, Feb 4, 2024 at 12:05 AM Paul Smith wrote: > > > I feel these proposals are > 1) not obvious in how they work, regardless of how they work, and > 2) largely possible without new syntax. > > The first of these is proven by the amount of communication so far. > The second is true except for maybe leaking some helper variables. I'm not sure I agree with both of these points but I'll think about them. One of the impetuses for providing these types of operators is to allow them to be used on the command line. Anything that requires breaking a single operation up into multiple separate lines and using temporary variables is quite annoying to manage on the command line. As well, "leaking some helper variables" is not necessarily a trivial thing in a large/complex makefile especially when a random assignment "somewhere else" far away in a different makefile (after inclusion) could break the local behavior. > For the original ?= these two points did not hold. When you > understand what kind of problem it solves, it is fairly clear that it > does so in a very reasonable way. > > What about adding only ?:= and !:= and forgetting about appending? The conditional operators have already been implemented and pushed: https://git.savannah.gnu.org/cgit/make.git/commit/?id=1eff20f6f64d00f588c218e265f8d3a81a8fb00b We are only right now discussing append operators. And, I don't know what you mean by "!:=". If you are simply trying to have a way to get the behavior of := combined with $(shell ...) as an operator, rather than writing it out, I'm not sure I see the point in that. It's not something I was considering. -- Paul D. Smith Find some GNU Make tips at: https://www.gnu.org http://make.mad-scientist.net "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
Re: Issue with 'src/variable.c'
On Wed, 2024-02-07 at 13:35 +0100, Gisle Vanem wrote: > src/variable.c doesn't compile: > variable.c(1642): error C2065: 'specificity': undeclared > identifier > variable.c(1658): error C2065: 'specificity': undeclared > identifier Thanks for this report. It's helpful to include information on the operating system and compiler suite you're using when reporting issues. In this case this code is only compiled on Windows: #if MK_OS_W32 ... Unfortunately I don't test on Windows regularly (e.g., before I push every commit) since I don't own a license for Windows. I use the free evaluation VMs from Microsoft but they expire every few months: if I have an instance that hasn't expired I'll use it but if not I wait to test until I either need to test something specifically on Windows, or else when I'm going to make a release. I will address this, thanks!
Re: Conditional append operator (was: Re: New conditional assignment facility)
On Sat, 2024-02-03 at 17:45 -0500, Paul Smith wrote: > Here's how I think the "append changes the type of the variable" > option works: I should have been more clear on my nomenclature. In my examples the column on the right is meant to describe what make has in its memory for a variable. So if the right column contains: FOO := a$b x$y that means that make knows a variable FOO, it is a simple variable, and its value is the string "a$b x$y". I didn't mean that the right column should be interpreted as an equivalent assignment a user might write in a makefile; so the above is NOT meant to say that you would expand the right side and get "FOO := a x". Sorry for the possible confusion. -- Paul D. Smith Find some GNU Make tips at: https://www.gnu.org http://make.mad-scientist.net "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
Conditional append operator (was: Re: New conditional assignment facility)
On Mon, 2024-01-29 at 09:52 +, Edward Welbourne wrote: > Perhaps it would be useful to enumerate the other types of assignment This seems useful. There are two options: the "append changes the type of the variable" option, and the "append doesn't change the type of the variable" option. Since := and ::= have identical behavior I didn't show both in the examples below. Here's how I think the "append changes the type of the variable" option works: Given: v1 = a$$b v2 = x$$y FOO = $(v1) FOO += $(v2) equals FOO = $(v1) $(v2) FOO := $(v1) FOO += $(v2) equals FOO := a$b x$y FOO = $(v1) FOO +:= $(v2)equals FOO := a$b x$y FOO := $(v1) FOO +:= $(v2)equals FOO := a$b x$y FOO = $(v1) FOO +:::= $(v2) equals FOO = a$$b x$$y FOO := $(v1) FOO +:::= $(v2) equals FOO = a$$b x$$y FOO = $(v1) ??? not sure. Maybe: FOO +!= echo '$(v2)' equals FOO = $(v1) x$$y ??? FOO := $(v1) ??? not sure. Maybe: FOO +!= echo '$(v2)' equals FOO = a$$b x$$y ??? Note that in all cases except the first (and !+=?), if the variables v1 or v2 were reset AFTER this assignment that change would have no effect on FOO. What this means is that you cannot use any assignment / append operator other than "=" and "+=" (and maybe "+!="?) with any variable that needs to contain an automatic variable like "$@" or "$<". An algorithm for the above non-+= operators might be something like: 1. Find the RHS type (simple vs. recursive) based on the append operator. 2. Evaluate the RHS of the variable as per its operator 3. If the LHS == simple && RHS == recursive: escape the LHS 4. If the LHS == recursive && RHS == simple: expand the LHS 5. Append the LHS and RHS values separated by a space 6. Set the type of the variable to the RHS type Here's how I think the "append doesn't change the type of the variable" option works: Given: v1 = a$$b v2 = x$$y FOO = $(v1) FOO += $(v2) equals FOO = $(v1) $(v2) FOO := $(v1) FOO += $(v2) equals FOO := a$b x$y FOO = $(v1) FOO +:= $(v2)equals FOO = $(v1) x$$y FOO := $(v1) FOO +:= $(v2)equals FOO := a$b x$y FOO = $(v1) FOO +:::= $(v2) equals FOO = $(v1) x$$y FOO := $(v1) FOO +:::= $(v2) equals FOO := a$b x$y FOO = $(v1) FOO +!= echo '$(v2)' equals FOO = $(v1) x$y FOO := $(v1) FOO +!= echo '$(v2)' equals FOO := a$b x An algorithm for the above non-+= operators might be something like: 1. Find the RHS type (simple vs. recursive) based on the append operator. 2. Evaluate the RHS of the variable as per its operator 3. If the LHS == simple && RHS == recursive: expand the RHS 4. If the LHS == recursive && RHS == simple: escape the RHS 5. Append the LHS and RHS values separated by a space 6. Don't change the type of the variable -- Paul D. Smith Find some GNU Make tips at: https://www.gnu.org http://make.mad-scientist.net "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
Re: Git repo outage
On Tue, 2024-01-30 at 01:13 -0700, Bob Proulx wrote: > Please make a bookmark of this URL to get out-of-band status of > system problems. > > https://hostux.social/@fsfstatus If you have a mastodon account you can follow that account as well if you prefer. Bob, note that the last update (7h ago) says things are still down: > Savannah services git, svn, hg, bzr, download and audio-video.gnu.org > are unavailable. I'm not sure if that's a typo, or if someone forgot to add the latest updates, or...?
Re: [Savannah-hackers-public] Strange behavior of "post a comment" on Savannah?
On Sun, 2024-01-28 at 17:10 +, Ineiev wrote: > Fixed, sorry for the trouble. Looks great, thanks!
Re: Handling of MAKEFLAGS
On Thu, 2024-01-11 at 00:37 -0500, Dmitry Goncharov wrote: > You are designing a new feature, aren't you? Specifically, the > ability to unset -e. If really needed, a makefile can reset -e on > the command line for submake and have submake do the work. > Alternatively, it is possible to introduce the opposite switch, just > like -S and -k. Thinking about it more I've decided I don't think this is needed. Why would -e be used? It means that the person invoking make decided that they want their environment variables to take precedence over variables in the makefile. I think this is a bad idea, but I don't think it's right for the _makefile_ to be able to override this decision and _disable_ the -e option again. Of course it's possible that the makefile added the -e option not the user on the command line but, well... as you say they can use a sub- make if they really want to override it. I just think the -e option is a bad idea in all the ways so I don't want to go to a lot of trouble to allow fancy behaviors. > > i agree that the makeflags business is overly complex. i feel, the > main issue is that makeflags serves two functions, it carries command > line switches to submake and it allows a makefile to set switches. Yes, that may be so. As you say it's kind of moot now. Plus, there's some elegance to allowing it, from the user's perspective, since that's how they set variables in their environment etc. as well. But it definitely leads to a lot of effort in the implementation to try to keep it all straight. -- Paul D. Smith Find some GNU Make tips at: https://www.gnu.org http://make.mad-scientist.net "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
Re: New append operators (was: Re: New conditional assignment facility)
On Sun, 2024-01-28 at 18:06 -0500, rsbec...@nexbridge.com wrote: > > FOO +:= bar > > > > can be interpreted as working like this: > > > > FOO := $(FOO) bar > > > > which is what you and others are arguing for. Or it can be > > interpreted as working > > like this: > > > > __FOO := bar > > FOO += $(__FOO) > > > > (where the value of __FOO is immutable). This is what I was > > thinking. > > I do not think the above two are equivalent. ?? They're definitely NOT equivalent. That's the point. What I was trying to say is that there are two DIFFERENT ways to interpret +:=. You can either interpret "FOO +:= bar" to behave the same as "FOO := $(FOO) bar" which is what you are suggesting. Or you can interpret "FOO +:= bar" to be more-or-less equivalent to writing: __FOO := bar FOO += $(__FOO) If and only if __FOO was not modified after this. Of course there is no way to guarantee that __FOO is not modified after this: there is no such thing as an immutable variable in GNU Make. So in that way this interpretation of "+:=" would be more powerful than anything you can already do in GNU Make today and this would be a truly new capability, not just a shorthand for "FOO := $(FOO) bar" (which you can already easily write if that's what you want). -- Paul D. Smith Find some GNU Make tips at: https://www.gnu.org http://make.mad-scientist.net "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
New append operators (was: Re: New conditional assignment facility)
On Mon, 2024-01-22 at 21:33 -0500, Dmitry Goncharov wrote: > On Mon, Jan 22, 2024 at 8:16 AM Paul Smith wrote: > > I don't understand the point you are making about +!=. > > If all new operators behave the same as +=, when the variable exists, > then +!= is not needed, because +!= would do the same as +=$(shell > ...). They are not equivalent since if the variable is recursive the +!= model would execute the shell script immediately, one time, and append the result, while += $(shell ...) would re-run the shell script every time the variable was expanded. In addition to efficiency, it could be a noticeable behavior if the shell script does something (like list files or obtain a date or something) which might change between invocations. In other words in this situation: foo = bar foo +!= echo baz then the value of foo would be "bar baz", while in this situation: foo = bar foo += $(shell echo baz) the value of foo would be "bar $(shell echo baz)". Of course you can rewrite it to be the equivalent, like this: foo = bar __foo := $(shell echo baz) foo += $(__foo) here bar has a value of "bar $(__foo)": as long as __foo was not reset then it would give the same result as +!=. -- Paul D. Smith Find some GNU Make tips at: https://www.gnu.org http://make.mad-scientist.net "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
New append operators (was: Re: New conditional assignment facility)
On Sat, 2024-01-27 at 17:45 -0500, rsbec...@nexbridge.com wrote: > My take on it is that +:= (because of the : ) means that you have to > resolve everything at that point. Yes, I understand what you are saying. The question is, is that the right conception? Here's another way to look at it: FOO +:= bar can be interpreted as working like this: FOO := $(FOO) bar which is what you and others are arguing for. Or it can be interpreted as working like this: __FOO := bar FOO += $(__FOO) (where the value of __FOO is immutable). This is what I was thinking. My argument is, if you want to write "FOO := $(FOO) bar" you can just write that today: you don't need "+:=" (you will have an extra leading space if FOO was not set already but that's unlikely to matter much). But if you want the second form it's tricky to do. It can also be argued that the second form is closer to the behavior of "+=" since "+=" keeps the pre-existing type of the variable rather than changing it. Although of course it's still special in some respects. -- Paul D. Smith Find some GNU Make tips at: https://www.gnu.org http://make.mad-scientist.net "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
Re: [Savannah-hackers-public] Strange behavior of "post a comment" on Savannah?
On Sat, 2024-01-27 at 16:04 -0600, G. Branden Robinson wrote: > At 2024-01-27T16:51:29-0500, Paul Smith wrote: > > Is anyone else seeing this strange formatting of the "Post a > > comment" section on Savannah? I attach a screenshot of what > > happens when I click the "(+)" next to the section title to add a > > new comment. > > Yes, I've been seeing it as well for the past several days. I > preferred the old behavior; the project I work on (groff) doesn't use > canned responses at all, so it is a waste of screen real estate for > me. Thanks for confirming Branden! I wasn't talking so much about the canned responses although I agree that since I don't have any it's a bit annoying to use the screen real- estate to show an empty box, rather than allowing my reply to take up the entire screen. Better would be to omit this section if there are no canned responses. But I was more referring to the messed up formatting at the bottom where the comment box overlaps with the horizontal lines and the title of the "Discussion" section appears to the right of the comment box instead of below it. -- Paul D. Smith Find some GNU Make tips at: https://www.gnu.org http://make.mad-scientist.net "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
Re: make manual feedback
On Mon, 2024-01-22 at 21:16 +, David Apps wrote: > I have some feedback about the document at the following address: Thanks for your feedback. I applied all these changes, or some form of them, except: > > Do not install executables here in this directory > > Perhaps delete "here". > > > Also do not install files that are modified in the normal course of > their use > > Perhaps change "install files" to "install in this directory any > files". These changes need to be made in the make-stds.texi file which is distributed by the gnulib project. You can reach them at bug-gnu...@gnu.org Cheers! -- Paul D. Smith Find some GNU make tips at: https://www.gnu.org http://make.mad-scientist.net "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
[Savannah-hackers-public] Strange behavior of "post a comment" on Savannah?
Is anyone else seeing this strange formatting of the "Post a comment" section on Savannah? I attach a screenshot of what happens when I click the "(+)" next to the section title to add a new comment. Is this the intended display result? I'm using Firefox 121.0.1 on GNU/Linux x86_64. -- Paul D. Smith Find some GNU make tips at: https://www.gnu.org http://make.mad-scientist.net "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
Re: New conditional assignm ent facility
On Sat, 2024-01-27 at 15:52 -0500, rsbec...@nexbridge.com wrote: > > I'm interested in peoples' opinions about which of these two > > implementations they would feel to be more "intuitive" or > > "correct". Also please consider issues of "action at a distance" > > where a variable is assigned in one makefile and appended to in > > some other makefile, potentially far away. > > Intuitive reading of this would seem that "bar=2 2 3" is better, as > +:= should force complete resolution of the string applied to bar, > not partial resolution of foo keeping an instance of $(foo) for > resolution later. Hm, maybe I'm just weird. Or maybe I chose a poor example. What if the example was like this: foo_ARGS = -a bar_ARGS = -b ARGS = $($@_ARGS) -x all: foo bar foo bar: ; cmd $(ARGS) $@ ARGS +:= $(shell gen-args) where the "gen-args" program outputs "-z". and now the value of ARGS would either be "$($@_ARGS) -x -z" using the method I was suggesting, or it would be " -x -z" using the alternative method where ARGS was converted into a simple variable. So using the first method make would run: cmd -a -x -z foo cmd -b -x -z bar and using the alternative method make would run: cmd -x -z foo cmd -x -z bar Is it still more intuitive? Maybe the answer is "well, just don't do that" :). Or maybe "+!=" could be used in this specific situation, but you get the idea. The problem is that when you write the assignment +:= it's not always so simple to know what the side-effects might be because you don't know what the current behavior of the variable is, and it might change in the future. Of course, that's always a problem with makefiles. -- Paul D. Smith Find some GNU make tips at: https://www.gnu.org http://make.mad-scientist.net "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
Re: New conditional assignment facility
On Mon, 2024-01-22 at 08:15 -0500, Paul Smith wrote: > Let's step back and I'll try to think more clearly about this. Sorry for the delay in replying. I can see that I was thinking about this one way but there's another way to look at it that I didn't think of. We are talking only about (a) append operators _other than_ +=, and (b) situations where the variable already has a value when the append operator is parsed. In all cases we would expand the right-hand side of the variable according to the assignment operator: e.g., if it were +:= we would immediately expand the RHS. My proposal was to keep the type of variable (recursive vs. simple) the same and then "fix up" the result of the RHS so it could be appended in a correct way. In this conception the operator applies ONLY to the RHS value, and will set the type of the variable only if the variable doesn't already exist, as a side-effect. The other way to think about it is that the assignment operator overrides the type of the variable as well: we would re-evaluate the LHS value then append the RHS. E.g., if it were +:= we would immediately expand the RHS as well and change the type of simple. In this conception the operator resets the type of the variable as its primary function, not just as a side-effect, and modifies not just the RHS value but also (possibly) the LHS value as well. An example to make this clearer: Given: foo = 1 bar = $(foo) foo = 2 bar +:= $(foo) foo = 3 bar += $(foo) $(info bar=$(bar)) In my original version, the result would be that "bar" is a recursive variable with the value "$(foo) 2 $(foo)" and the output of the info function would be "bar=3 2 3". In the alternative version, the result would be that "bar" is a simple variable with the value "2 2 3" and the output of the info function would obviously be "bar=2 2 3". I'm interested in peoples' opinions about which of these two implementations they would feel to be more "intuitive" or "correct". Also please consider issues of "action at a distance" where a variable is assigned in one makefile and appended to in some other makefile, potentially far away. This discussion has really helped me crystallize the differences and should make the resulting documentation, if/when it's written, much more clear so I definitely appreciate it! -- Paul D. Smith Find some GNU make tips at: https://www.gnu.org http://make.mad-scientist.net "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
Re: feature requests: $(__FILE__) and $(__LINE__) textual macros
On Sat, 2024-01-27 at 20:45 +0100, Basile Starynkevitch wrote: > NB I might perhaps implement such a feature if (and only if) I don't > have any copyright assigment to find. In my GCC contributing > experience fifteen years ago, that administrative step was really > painful. I am too old to start such nightmares again. The GNU project, of which GNU Make is a part, still does require copyright assignment for any contribution of "significant" size, which generally means patches that are more than 15 or so lines long. Assignment has gotten simpler: in many jurisdictions (including some non-U.S. countries) it can all be done online. But if you work for a company which has a claim to the work you did you would have to get a disclaimer from them as well which can be onerous (depending on the company of course). Cheers! -- Paul D. Smith Find some GNU make tips at: https://www.gnu.org http://make.mad-scientist.net "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
Re: feature requests: $(__FILE__) and $(__LINE__) textual macros
On Sat, 2024-01-27 at 20:27 +0100, Basile Starynkevitch wrote:
> > It would be great if you could provide examples where these would
> > be
> > useful, especially examples that are not already covered by the
> > output
> > of the -p option to GNU Make.
>
> make -p don't show (unfortunately) the line number in makefiles.
> Alternatively, a runtime option for make -p (perhaps
> --show-line-numbers) would be nice.
It definitely DOES show line numbers. For example for a variable
definition:
# makefile (from 'Makefile', line 361)
PACKAGE_NAME = GNU Make
and for a rule definition:
all: alloca.h
# ...
# recipe to execute (from 'Makefile', line 490):
$(MAKE) $(AM_MAKEFLAGS) all-recursive
> > I'm not saying we shouldn't introduce these, although I think you
> > misunderstand how tricky it would be to use them (for example, if
> > you set:
> >
> > FOO = $(__LINE__)
>
> This would be expanded at Makefile parsing time. Not at function
> invocation time.
I'm not sure what you mean by "this". It would be helpful to my
understanding if you used the example I provided and showed what value
you expected BAR to have: 1 or 3? Then I could be sure I understood
what you meant.
Macros and functions in recursive variable assignments ("=") are not
expanded when the variable is defined. They are expanded when the
variable is referenced. For example if you have:
bar = 1
FOO = $(bar)
bar = 2
all: ; @echo $(FOO)
then the output will be "2", not "1", because $(bar) is not expanded
when FOO is defined, it's expanded when $(FOO) is expanded (in the
recipe, in this example).
Are you suggesting that $(__LINE__) would somehow be a special case and
NOT work like this? So if I have:
bar = 1
FOO = $(bar) $(__LINE__)
bar = 2
all: ; @echo $(FOO)
the output I got would be "2 2" instead of "2 4"?
In other words, make would parse the value of FOO looking for
references to the special variables __LINE__ and __FILE__ and expand
only those, but not other macros or functions?
> If I started to implement it, I would add
>
> FT_ENTRY ("__LINE__", 0, 0, 0, func__LINE__),
>
> in GNU make's src/function.c file.
This would almost certainly not do what you want.
> So my intuition is that this feature is easy to implement.
I don't think you're correct about that. But any discussion of the
implementation details is premature: the behavior must be defined
first.
--
Paul D. Smith Find some GNU make tips at:
https://www.gnu.org http://make.mad-scientist.net
"Please remain calm...I may be mad, but I am a professional." --Mad
Scientist
Re: How to tell make to not try to remake source files?
On Sat, 2024-01-27 at 20:00 +0100, Antonio Diaz Diaz wrote: > In order to increase the efficiency of the build, I added empty > recipes to my makefiles to prevent 'make' from trying to remake > source files: A simpler and more effective way to increase efficiency and reduce the output of -d is to remove all the built-in rules. Instead of defining new pattern rules for these targets, remove existing pattern rules that match them. Make won't try to "build source files" if there's no pattern rule it can use to do so. If you have GNU Make 4.0 or higher, you can simply add: MAKEFLAGS += -r to your makefile and it will remove all the built-in pattern rules. If you want to continue to use older versions of GNU Make, you can get mostly-equivalent behavior by adding this to your makefile: .SUFFIXES: %:: %,v %:: RCS/%,v %:: s.% %:: SCCS/s.% -- Paul D. Smith Find some GNU make tips at: https://www.gnu.org http://make.mad-scientist.net "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
Re: feature requests: $(__FILE__) and $(__LINE__) textual macros
On Sat, 2024-01-27 at 18:06 +0100, Basile Starynkevitch wrote: > For non-trivial GNUmakefile-s on Linux it would be nice to have a > $(__FILE__) and $(__LINE__) textual macros of GNU make. It would be great if you could provide examples where these would be useful, especially examples that are not already covered by the output of the -p option to GNU Make. I'm not saying we shouldn't introduce these, although I think you misunderstand how tricky it would be to use them (for example, if you set: FOO = $(__LINE__) BAR := $(FOO) then will BAR get line number 3, where the variable reference $(FOO) is expanded, or the line number 1, where the variable FOO is defined?) But we need to understand the use-cases to evaluate the request. -- Paul D. Smith Find some GNU make tips at: https://www.gnu.org http://make.mad-scientist.net "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
Re: New conditional assignment facility
On Sun, 2024-01-21 at 14:22 -0500, Dmitry Goncharov wrote: > Let us clarify the goal of these enhancements? > i assumed that the goal of these enhancements was to allow code like > hello+:=$(world) > create 'hello' as a simple variable, if 'hello' does not exist yet. > > After reading your != example, i realize i misunderstood the meaning > of option one. Let me correct myself. > > If the only goal was to allow +:= create a simple variable, then can > we do the following? > "If no variable with this name exists, then +:= creates a simple > variable, and +:::= creates an immediately-expanded-and-escaped > variable. Otherwise, +:= and +:::= behave the same as +=". > If we go with this, then there is no need for +!=, because +!= would > behave as +=. Similarly, there is no need for +::=, because +::= > would behave as +:=. I agree that we don't need to treat +:= and +::= differently. They are just different names for the same operator. I don't understand the point you are making about +!=. Maybe you're misremembering what the != operator does? Let's step back and I'll try to think more clearly about this. The variable assignment operators describe two things: how to handle the RHS value and what the resulting flavor of the variable will be. Although we have four assignment operators, once the assignment is complete there are only two flavors of variables: either recursive or simple: =- Don't expand the RHS, --> recursive variable := - Expand the RHS, --> simple variable ::= - Expand the RHS, --> simple variable :::= - Expand and escape the RHS, --> recursive variable != - Run the RHS as a shell script, --> recursive variable. If an appending operator is applied to a variable that doesn't exist already, then the behavior is the same as if we used the non-appending operator in all cases. So if the variable doesn't exist, "+=" behaves like "=", "+:=" behaves like ":=", "+::=" behaves like "::=", "+:::=" behaves like ":::=", and "+!=" behaves like "!=". That's simple. What about a variable that does exist already? I think that we can agree that the append operator cannot change the type of a variable that already exists. If the variable was recursive before it must stay recursive afterward; the same for simple variables. If we agree on the above then the only question is how the RHS of the assignment is treated in each case. For each possible appending operator we have to answer two questions: 1) What is the RHS behavior when appending to a RECURSIVE variable? 2) What is the RHS behavior when appending to a SIMPLE variable? We have to preserve the existing behavior for "+=". So for "+=", the answers must be: += Recursive: the RHS will be appended without expanding. Simple: the RHS will be expanded then appended. My understanding of your suggestion is that ALL the operators should behave the same as "+=" in this situation and the specific operator doesn't matter. I just don't think that will work. It will be almost impossible to use these appending operators reliably if this is how they behave. Here is a possible solution which will be hard to document, but will probably end up giving users what they expect: +:= Recursive: the RHS will be expanded and escaped then appended. Simple: the RHS is expanded then appended +::= Recursive: the RHS will be expanded and escaped then appended. Simple: the RHS is expanded then appended +:::= Recursive: the RHS will be expanded and escaped then appended. Simple: the RHS is expanded then appended +!= Recursive: the RHS will be run as a shell script then appended. Simple: the RHS is run as a shell script, expanded, then appended I believe that with this behavior you will always get the equivalent of, "the RHS is handled according to the assignment operator, and the expansion of the resulting variable will be as expected based on the flavor (recursive vs. simple)". The only one of these which is slightly off is the +!= to a simple variable since the result of the shell script cannot be stored as a recursive value. Instead I expand it immediately. I can provide examples of the results of this if needed for understanding; I'm working on a new regression test file for it. -- Paul D. Smith Find some GNU make tips at: https://www.gnu.org http://make.mad-scientist.net "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
Re: New conditional assignment facility
On Sat, 2024-01-20 at 22:18 -0500, Dmitry Goncharov wrote: > > Either we could follow the example of "+=" and say that the assignment > > type in "+:=" only takes effect if the variable doesn't already have a > > type but if it does that type is preserved, so in the above example FOO > > would continue to be recursively expanded in spite of "+:=", so FOO has > > a value of "$(bar) $(biz)" and $(FOO) gives "1 2". > > > > Or we could say that "+=" is a special case where we follow the type of > > the existing variable, but for the other operators we first expand the > > right hand side then append the result regardless of the original type. > > So in the above example FOO is still a recursive variable, BUT $(baz) > > is expanded immediately before appending so the value of FOO would be > > "$(bar) yy" and $(FOO) gives "1 yy". > > > > Neither of these is great, in that they both will cause people to be > > surprised, in different situations. > > i like option one. It is simple to explain in the manual and, as far > as i can tell, option one does what users want. > As long as the manual says something like "when there is no variable > +:= creates a simple variable, otherwise +:= behaves the same as :=" > is there still room for surprises? I think you wrote that wrong: I think you mean "otherwise +:= behaves the same as +="... ? I think the behavior here would be very surprising in a number of situations as I'll try to show below. > i suspect option two is a lot trickier to use in a makefile. Option > two introduces a doubt in the mind of a makefile author. If the > makefile author knows that all the appends +=, :+=, ::+=+, :::+= Just for clarity, it's "+=", "+:=", "+::=", "+:::=", and "+!="; the plus is the first character in the token, not right before the "=". > follow the variable flavor, once the variable is created, then the > author sees that a variable is recursive at the top of a makefile and > knows anything can be appended to the variable at the bottom of the > makefile and the value will contain that anything at build time. If > we go with option two then the author does not have this knowledge. > In your example, one scenario is that the author misses that the > assignment is +:= and sets biz to 2 and expects that FOO contains "1 > 2" at build time. Another scenario is that 'FOO +:= $(biz)' is > introduced long after 'biz = 2'. Similarly, if the author wants to > introduce a +:= assignment somewhere in a makefile, they have to > check that the makefile does not contain another assignment later. In > our example, if the author wanted to introduce FOO +:= $(biz) they > will have to check that biz is not assigned later. I don't think I agree with you here. Let's take one obviously bad case: the != operator. I don't see any legitimate way that this can be used if we choose option one. Suppose we have: $(X)foo != echo hello foo +:= $(BAR) Now what do we do? We clearly can't say that the RHS of the append assignment should be treated as a shell script! It can't work to say that the value to be appended _might_ be appended using simple expansion if X has a value, _or else_ be run as a shell script and append the result if X is empty. And similarly for the other way around: it won't work if the value was originally assigned with ":=" and then you use "+!=" and instead of expanding the shell command it simply expands and appends the value. The idea behind option two is that you don't need to know what other settings of the variable had previously been created. The only thing you care about is how you want to handle THIS assignment; that is, you expand (or not) the RHS of THIS assignment according to the operator, then append that value. So for example if you see "+!=" you know that the RHS of this assignment will definitely be expanded as a shell script, then the results will be appended to the variable. The question is what happens in this scenario: foo = $(bar) foo +:= $(baz) What we would like to see is that the RHS of the "+:=" is expanded immediately (if the user didn't want it to be expanded immediately then they'd obviously not use "+:=") then appended. But this is kind of gross because we're appending an already-expanded value to a recursive variable, which means that already-expanded value will be expanded AGAIN when the variable is expanded which is not what you want. Similarly, what if we have: foo := $(bar) foo +:::= $(baz) Here the foo variable is marked simple, but we are appending an escaped value to it which won't be expanded later. Maybe we need to consider escaping/expanding values properly for the variable they are to be assigned to, after we expand them based on the current operator. I will try to write down what I'm thinking in a separate email, maybe as a table. The need for such a table of course is depressing because it means we can't just have a simple rule. But I just don't think that a simple rule can work given all the
Re: [bug #64551] Possible null pointer dereference on the function get_buffer
On Sun, 2024-01-21 at 12:00 +0800, Haoxin Tu wrote: > May I know if you are planning to propose a fix for it? I checked the > implementations of other `make` versions a bit further, and as far as > I can tell, the issue exists from the older make-4.0.90 (2014-9-30) > to the newest version of make (make-4.4.0.91). That's incorrect. As Martin explained, and I mentioned in my replies, this issue was resolved back in 2017 and the fix is available starting in GNU Make 4.3 and above. In that release, the OUT_OF_MEMORY() macro has been replaced with an out_of_memory() function call, and neither that function nor any function it calls will try to allocate memory and so it cannot have the same behavior as the older code. In the current release, out-of-memory failures write a static buffer to a file descriptor then exit, without returning or trying to allocate more memory. Here is the relevant code from the current GNU Make 4.4.1 release: https://git.savannah.gnu.org/cgit/make.git/tree/src/misc.c?h=4.4.1#n288 https://git.savannah.gnu.org/cgit/make.git/tree/src/output.c?h=4.4.1#n532 https://git.savannah.gnu.org/cgit/make.git/tree/src/misc.c?h=4.4.1#n426 As an aside, all the versions of GNU Make that end in ".9x" such as the ones you refer to above, 4.0.90 and 4.4.0.91, are beta or release candidate releases. They are not fit for production use. Any release which is made available on the https://alpha.gnu.org/gnu/ site is a pre-release and should only be used for testing the release. You should only use releases with non-".9x" versions. You can find these releases at the official site https://ftp.gnu.org/gnu/ and they are announced at https://savannah.gnu.org/projects/make/ -- Paul D. Smith Find some GNU make tips at: https://www.gnu.org http://make.mad-scientist.net "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
Re: [bug #64551] Possible null pointer dereference on the function get_buffer
On Sat, 2024-01-20 at 23:37 +0800, Haoxin Tu wrote: > But I don't understand why the second invocation of `xrealloc` can > not return zero, I apologize for any imprecise information I provided > in the previous emails. Because of what I said in my original reply: > the entire point of xrealloc is that it never returns 0. Look at the implementation of xrealloc(): void *result = malloc (size ? size : 1); if (result == 0) OUT_OF_MEM(); return result; We know that OUT_OF_MEM() never returns. So there's no way this function can return 0. It will, as Martin suggests, recurse infinitely (one assumes) because fatal() calls xrealloc() again, and malloc() will return 0, so it will call fatal(), which calls xrealloc() again, and malloc will return 0, so it will call fatal(), etc. etc.--this is what I meant by my imprecise comment "infinite loop" I should have said "infinite recursion". As a reminder this is moot: this code has been rewritten and even the infinite recursion problem was removed from the code back in 2017. -- Paul D. Smith Find some GNU make tips at: https://www.gnu.org http://make.mad-scientist.net "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
Re: Re: Segmentation Fault on Exported Resursively Expanded Variable
On Tue, 2024-01-16 at 06:59 +, MIAOW Miao wrote: > (gdb) bt > #0 recursively_expand_for_file (v=v@entry=0xad5740, > file=file@entry=0x0) at src/expand.c:119 > ... > #20 0x0041acec in main (argc=, argv= out>, envp=) at src/main.c:2918 This is not as helpful because you've elided the entire stack trace. We can infer it from Henrik's stack trace but he is working with modified code so getting it from a vanilla copy would be better. >From Henrik's investigation and the fact that I cannot reproduce it, I'm pretty sure it's related to your environment; almost certainly to the environment variables in your environment when you invoke make. Dmitry says he can't reproduce it in the latest code from Git, but since I can't repro it with either 4.4 or 4.4.1 I'm not sure that's determinative. If Dmitry CAN repro it reliably with vanilla 4.4 or 4.4.1 but not with the latest code then we can say it's been resolved.
Re: Segmentation Fault on Exported Resursively Expanded Variable
On Mon, 2024-01-15 at 11:21 +, MIAOW Miao wrote: > I found name of exported resursively expanded variable with $(shell > ...) cannot be too long in gnu make version >= 4.4, otherwise a > segmentation fault is triggled. I'm not sure if variable-name-too- > long is a bug. However, make is > supposed to tell me what's going wrong. > > Here is a Makefile that can reproduce the segmentation fault: > > THIS_LONG_VARIABLE_NAME_PREDUCE_THE_ERROR= $(shell echo hello) > > exportTHIS_LONG_VARIABLE_NAME_PREDUCE_THE_ERROR > > > > all: ; echo "abc" I was not able to reproduce this problem, either with my own build of GNU Make 4.4.1 or with a binary extracted from the RPM from the link you provided. I tried running under valgrind and with a binary compiled with ASAN, with and withoug debugging enabled, ran the test 1000 times. I also tried GNU Make 4.4. If you can generate a coredump please examine it with GDB and send along at least the backtrace. -- Paul D. Smith Find some GNU make tips at: https://www.gnu.org http://make.mad-scientist.net "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
Re: New conditional assignment facility
On Thu, 2024-01-11 at 14:28 +0100, Alejandro Colomar wrote: > > > alx@debian:~/tmp$ cat Makefile > > > var ?= foo > > > var ?+= bar > > > $(info $(var)) > > > alx@debian:~/tmp$ make-9000 > > > foo bar > > > make: *** No targets. Stop. > > > alx@debian:~/tmp$ make-9000 var=foo > > > foo > > > make: *** No targets. Stop. > > > alx@debian:~/tmp$ var=foo make-9000 > > > foo > > > make: *** No targets. Stop. Sorry Alejandro; maybe you need to rewrite your examples again without all the corrections, because I don't understand what you mean. In all your examples, the value of var is set by the first line if it's not already set: var ?= foo After this line, var will either be "foo" or it will be whatever value var had before that assignment (from the environment or command line or whatever, it doesn't matter). But it's definitely defined. Once that happens, any subsequent "?" assignments, of any type, are simply ignored and useless because "?" means "set if not defined" but after the above line, var is always defined. So it doesn't matter if the next line is "var ?= bar" or "var ?+= bar" or whatever: it is just ignored. -- Paul D. Smith Find some GNU make tips at: https://www.gnu.org http://make.mad-scientist.net "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
Re: New conditional assignment facility
On Thu, 2024-01-11 at 01:44 -0500, Paul Smith wrote: > I've implemented a new capability for conditional assignments (not > pushed yet). > > After these changes, a "?" can precede any type of assignment > operation, not just "=", and make it conditional (that is, it only > takes effect if the variable is not already set). > > There is one question I wanted to ask for opinions on: what should we > do with the "?+=" operator? Having thought about this more the answer seems obvious. Better would be to say that BOTH "?" AND "+" are modifiers to assignment statements, and that you can have only one of them; this makes sense since either you want to set a value if it doesn't exist or you want to append to a value that does exist, but not both. Thus, the "base" assignment operators would be "=", ":=", "::=" (for POSIX), and ":::=". Then you could prefix any of those with either "?" so the assignment only happens if the variable is not defined, or "+" so the assignment is appended to any existing value. So we would allow assignments like "+=", "+:=", "+::=", "+:::=" as well as the "?" variants. This is useful because something like "+:=" has long been requested. So the new confusion becomes, what happens if you use "+" to append to an existing variable that has a different type? Due to decades of history (and, to be honest, significant technical incentive), we have to say that in this case: bar = xx biz = yy FOO := $(bar) FOO += $(biz) bar = 1 biz = 2 FOO is a simply-expanded variable and $(biz) is expanded immediately even though it uses a "+=" assignment, and FOO is "xx yy". But then, what do we say about this case: bar = xx biz = yy FOO = $(bar) FOO +:= $(biz) bar = 1 biz = 2 ? There appear to be two options: Either we could follow the example of "+=" and say that the assignment type in "+:=" only takes effect if the variable doesn't already have a type but if it does that type is preserved, so in the above example FOO would continue to be recursively expanded in spite of "+:=", so FOO has a value of "$(bar) $(biz)" and $(FOO) gives "1 2". Or we could say that "+=" is a special case where we follow the type of the existing variable, but for the other operators we first expand the right hand side then append the result regardless of the original type. So in the above example FOO is still a recursive variable, BUT $(baz) is expanded immediately before appending so the value of FOO would be "$(bar) yy" and $(FOO) gives "1 yy". Neither of these is great, in that they both will cause people to be surprised, in different situations. Given that, I'm leaning more towards the second option above, which leaves "+=" as a special case but seems more useful and less confusing overall. Comments welcome. -- Paul D. Smith Find some GNU make tips at: https://www.gnu.org http://make.mad-scientist.net "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
New conditional assignment facility
I've implemented a new capability for conditional assignments (not pushed yet). After these changes, a "?" can precede any type of assignment operation, not just "=", and make it conditional (that is, it only takes effect if the variable is not already set). So for example, in addition to "?=" which creates a recursive variable if the variable is not set yet, GNU Make will support "?:=" which creates a simple variable if the variable is not set yet. Of course if it's already set then the right-hand side of the assignment is not expanded. Similarly the assignments "?::=" and "?:::=" are also supported. There is one question I wanted to ask for opinions on: what should we do with the "?+=" operator? On its face this operator is useless; it's identical to "?=" since if we only append if the variable was not set we're just "appending" to the empty value. Maybe this is right and we should do it this way just to make sure all uses are aligned. Or maybe we should say the "?+=" operator isn't supported and give an error since it has no function, lest people be confused by it. Another option would be to do the inverse for this operator, so "?+=" would only append if the variable WAS already set, else do nothing. I'm pretty uncomfortable with this inversion of expectation, and I'm not sure I see a good use-case for it. But I thought I'd mention it in case others do. -- Paul D. Smith Find some GNU make tips at: https://www.gnu.org http://make.mad-scientist.net "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
Re: Handling of MAKEFLAGS
On Wed, 2024-01-10 at 17:20 -0500, Dmitry Goncharov wrote: > > As an example, for the -e change I experimented with simply going > > through the variable database and switching the origin from o_env > > to o_env_override or vice versa. > > Do you mean an alternative fix for > https://savannah.gnu.org/bugs/?64803? > Do i understand your idea correctly that you want to import all env > variables as usual with origin o_env and then decode switches and > then look if -e was specified and then go through the db and replace > o_env with o_env_override? Correct. In fact I implemented this and it worked... except that some of your test cases (I really appreciate your attention to detail writing tests; I know it can be a thankless task so I definitely want to remember to say "thank you"! :)) failed. Investigating why I discovered the issue was as I mentioned below; once we have set the flag for -e (the env_overrides global variable) there's no way to unset it. > > This works great EXCEPT that if we disable the -e option via > > MAKEFLAGS, it doesn't actually change the global setting back > > again; a switch only "enables" but the _lack_ of a switch never > > "disables". > > right. > > > > > In order to make this work we'd need to have a way to reset the > > global settings to their default values. > > Here, i lost track. What do you mean by "this"? Do you mean replacing > o_env with o_env_override? Sorry, I rambled a bit there. What I was thinking was that the handling of MAKEFLAGS would be changed so that the content of the MAKEFLAGS variable would be considered the source of truth, and the values of the global variables set by the command_switch array etc. would only be convenient shortcuts for that information. In particular, every time MAKEFLAGS is changed we would first _reset_ all the global variables back to their default values effectively undoing whatever settings were made by the previous value of MAKEFLAGS, then we would re-parse MAKEFLAGS from scratch and set whatever values were there. By doing this we would ensure that, for example, if you have: MAKEFLAGS += -e MAKEFLAGS := $(subst e,,$(word 1,$(MAKEFLAGS))) \ $(wordlist 2,$(words $(MAKEFLAGS),$(MAKEFLAGS)) then after the first MAKEFLAGS assignment we'd reset the global option variables to their default (env_override = 0), then parse MAKEFLAGS which sets env_override = 1. Then after the second MAKEFLAGS assignment we'd reset the global option variables to their default so env_override = 0, then after we parse MAKEFLAGS the "e" option is not set anymore and env_override is left 0. After all that, we can go through the variables and reset the override status o_override vs. o_env_override if the value changed. Or, maybe there's a better way to handle that; maybe for example we should consider chaining variable sets like we do for target-specific variables and inheritance, and keeping environment variables in a different set and swapping the order of "env" vs "make" variable sets. But this might be complicated, there are some special cases for handling the global set. Since I actually consider -e to be a terrible feature and would never consider using it myself, maybe it's better to do the stupid, simple thing and just go through all the variables and reset them :)
Handling of MAKEFLAGS
Hi Dmitry; I was looking over your patches for dealing with various problems handling command line issues such as not handling -e properly and appending to pattern-specific variables. These are good patches but I'm getting more and more uneasy with the complexity around MAKEFLAGS and I wonder if there's a way to make it better. As an example, for the -e change I experimented with simply going through the variable database and switching the origin from o_env to o_env_override or vice versa. As far as I can tell there's no situation in which any variable should be o_env if -e was set, or o_env_override if -e was not set, so we don't need to worry about preserving a previous state. This works great EXCEPT that if we disable the -e option via MAKEFLAGS, it doesn't actually change the global setting back again; a switch only "enables" but the _lack_ of a switch never "disables". In order to make this work we'd need to have a way to reset the global settings to their default values. This means we'd need to reapply all the settings. So I wondered if maybe it wouldn't be worthwhile to change the handling of MAKEFLAGS so the value of MAKEFLAGS was considered the "source of truth" as to what flags were set, and every time we re-parsed it we would first reset all the global state settings back to their defaults then re-parse MAKEFLAGS as if it were the first time. Does this make sense? Have I overlooked any issues here?
Re: How to create symlinks for shared library with soname
On Mon, 2024-01-01 at 04:20 +0800, lijh8 wrote: > libtool creates both symlinks to the real library file. > But CMake creates one symlink to the real file and another symlink to > the first symlink. > > I'm sticking with manual Makefile but which way should I follow? First, I don't think this is a useful place to look for answers since it doesn't really matter to make which way you choose. There's no difference between the two options except that if you use a "chained link" model then conceivably you could avoid replacing the "outer" link and just replace the "inner" link if the major so version doesn't change. With the libtool method you would always replace both links. But in reality your makefile will always replace both links anyway; it doesn't seem useful to add the complexity needed to avoid it. So, there's no difference. Remember that symlinks are expanded by the _kernel_ when you open the file; it's not possible to tell the difference unless you go out of your way to do so by checking for symlinks using a special system call. -- Paul D. Smith Find some GNU make tips at: https://www.gnu.org http://make.mad-scientist.net "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
Re: [mailop] DKIM / slippery slope gmx.de
On 18/12/2023 10:18, ml+mailop--- via mailop wrote: And it seems none of the extra requirements do anything against spam, because the spammers can (and do, see above) easily implement all of those. DKIM (and SPF) aren't anti-spam measures, and have never been promoted as such. They're anti-forgery measures. Spam filters handle reputation of things. One thing they can do is track reputation of sender domains. When forgery is possible, then that means that spammers can piggy-back on the good reputation of big companies like Google, Amazon, etc. They send mail pretending to be from someth...@amazon.com. There's no reliable way for the recipient to know that it's not actually from Amazon, so the recipient has to either: - let the mail through (because it says it's from Amazon, so must be OK) - damage the reputation of Amazon (because spam comes from amazon.com) - or don't use the sender domain for reputation tracking, because it's unreliable The first two options are obviously bad, and the third takes away a big tool from the anti-spam arsenal. When you have SPF and/or DKIM, then you've essentially prevented forgery (yes, you may have introduced other problems, but that's by-the-by). So, it's irrelevant that spammers can implement these features - that's actually good - the spammers can't use a trustworthy sending domain to try to trick spam filters, so the spam filter can track the reputation of the REAL sending domain, and spammers get punished and the trustworthy domains (theoretically) don't. Paul ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
GCC 12.3 ICE: format(printf...) failing in C++ with virtual inheritance
I've tried this with both older versions as well as GCC 12.3 (latest I
have access to). This is on GNU/Linux on x86_64.
I have the following code:
#include
class Exception : public std::exception
{
public:
Exception(const char* text, ...)
__attribute__((format(printf, 2, 3)));
};
void foo()
{
throw Exception("something bad");
}
this works fine.
However, due to some diamond inheritance I need to switch to virtual
inheritance here:
#include
class Exception : public /**/ virtual /**/ std::exception
{
public:
Exception(const char* text, ...)
__attribute__((format(printf, 2, 3)));
};
void foo()
{
throw Exception("something bad");
}
this does not work AT ALL.
First, the extra virtual infrastructure means that the offsets we use
(note we need to add one to the format parameters anyway due to the
this pointer I assume) are wrong:
/tmp/virt.cpp:7:45: error: 'format' attribute argument 2 value '2'
refers to parameter type 'int'
7 | __attribute__((format(printf, 2, 3)));
| ^
Just adding 1 to this, for 3, 4, doesn't help:
/tmp/virt.cpp:7:45: error: 'format' attribute argument 2 value '3'
refers to parameter type 'const void**'
7 | __attribute__((format(printf, 3, 4)));
| ^
And if I add 2 instead so it's 4,5 instead, I get an ICE:
/tmp/virt.cpp: In function 'void foo()':
/tmp/virt.cpp:12:36: error: 'format' attribute argument 2 value '4' exceeds
the number of function parameters 2 [-Werror=attributes]
12 | throw Exception("something bad");
|^
/tmp/virt.cpp:12:36: internal compiler error: in get_constant, at
c-family/c-format.cc:323
0x7fba675a3082 __libc_start_main
../csu/libc-start.c:308
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
Re: Bug with $(info xxx) in 4.2.1
On Thu, 2023-12-07 at 11:38 -0500, Dmitry Goncharov wrote: > On Tue, Dec 5, 2023 at 12:01 AM Aaron Williams > wrote: > > > What is happening is I will get the error: > > *** recipe commences before first target. Stop. > > At the line with $(info xxx) unless I do not precede it with a tab. > > This error is expected. A tab precedes a recipe. > It does not matter what the recipe contains info or no info. It is > still a recipe and should be preceded by a rule definition. I don't think it's quite that simple. In make it's fine to have a make line indented with a TAB, that is not part of a recipe. If a line appears outside of the context of a rule, then leading whitespace is ignored. This can be seen by the example given, where the variable assignment line did not generate an error. You can do this simpler experiment without the ifeq, which is irrelevant for this issue: FOO = bar $(info baz) all:; (where the first two lines are indented with TAB). Here you will see that make accepts the first line but fails on the second line: $ make Makefile:2: *** recipe commences before first target. Stop. The reason for this is that make tries to understand what kind of line it has, BEFORE it expands the line. You can tell it is not expanded because the info function's output is not shown. So in the first line, make sees that it's a variable assignment and it accepts it. However make doesn't know what kind of line the second line is, and before it expands the content and realizes that the result would be the empty string it generates this error. Just as a point of order, it's a really, REALLY bad idea to indent non- recipe lines with TAB. While it's not technically illegal it will cause your makefiles to be very brittle; if someone were to add a rule line before this ifeq, then all of a sudden these lines would become part of a recipe and could lead to a lot of frustration and confusion. I recommend, in the strongest of terms, that you do not ever use TAB in makefiles anywhere other than for indenting recipe lines. However, this behavior should probably be considered a bug. Aaron, it would be helpful if you could file this as a bug in Savannah: https://savannah.gnu.org/bugs/?group=make=additem you don't have to make an account there, if you don't want to.
Re: make-4.3 on Linux x86_64 fails features/output-sync test
On Mon, 2023-11-27 at 15:27 -0500, Dennis Clarke via Bug reports and discussion for GNU make wrote: > GNU Make 4.3 Is the failure repeatable? Have you tried it with the latest version of GNU Make? It certainly doesn't fail on my system (which is, obviously, also running x86_64 GNU/Linux). But, the output sync tests have in the past sometimes been sensitive to performance issues etc.
Re: Obs Shader Filter faild to install
On Wed, 2023-11-15 at 08:54 +0100, Jean-François Hicter wrote: > ==> Lancement de build()… > make : option invalide -- 'D' Indeed, "-D" is not a valid option for GNU Make. However, we cannot help more than that because the makefile you are using has disabled all the normal output, which means we can't see the command line being invoked. You can try running "make --trace" if you have a sufficiently-new version of GNU Make and it will print the command line being invoked. Otherwise you'll have to find this rule in the makefile and see what it's doing. Alternatively, and probably more productively, you can ask for help from the people who created the Obs Shader Filter software and presumably know more about their build system. This is a problem with their makefiles, not with GNU Make itself. Cheers!
Re: Prerequisites and .DEFAULT -- what am I doing wrong?
On Tue, 2023-11-07 at 22:02 +0400, Ivan Shapovalov wrote: > However, when I run `make` on this Makefile, the recipe for > `build-base-image` is not run, despite that it is specified as a > prerequisite for the `.DEFAULT` target: >From the docs: .DEFAULT The recipe specified for .DEFAULT is used for any target for which no rules are found (either explicit rules or implicit rules). See Defining Last-Resort Default Rules. If a .DEFAULT recipe is specified, every file mentioned as a prerequisite, but not as a target in a rule, will have that recipe executed on its behalf. See Implicit Rule Search Algorithm. This talks only about the recipe; it doesn't say anything about prerequisites, and, in fact, prerequisites of .DEFAULT are ignored.
Re: Upgrade to F39: Disk Requirements: At least 5633 MB more space needed on the / filesystem.
On Tue, Nov 7, 2023 at 7:19 PM Jeffrey Walton wrote: > > > > Thanks, Peter: > > > > > > # df -h > > > Filesystem Size Used Avail Use% Mounted on > > > devtmpfs 4.0M 0 4.0M 0% /dev > > > tmpfs 16G 194M 16G 2% /dev/shm > > > tmpfs6.3G 1.7M 6.3G 1% /run > > > /dev/mapper/fedora_localhost--live-root 69G 68G 0 100% / > > > tmpfs 16G 36M 16G 1% /tmp > > > /dev/sda1974M 280M 627M 31% /boot > > > /dev/mapper/fedora_localhost--live-home 794G 397G 357G 53% /home > > > /dev/loop0 128K 128K 0 100% > > > /var/lib/snapd/snap/bare/5 > > > /dev/loop256M 56M 0 100% > > > /var/lib/snapd/snap/core18/2284 > > > /dev/loop1 117M 117M 0 100% > > > /var/lib/snapd/snap/core/14946 > > > /dev/loop356M 56M 0 100% > > > /var/lib/snapd/snap/core18/2745 > > > /dev/loop4 165M 165M 0 100% > > > /var/lib/snapd/snap/gnome-3-28-1804/161 > > > /dev/loop5 165M 165M 0 100% > > > /var/lib/snapd/snap/gnome-3-28-1804/198 > > > /dev/loop666M 66M 0 100% > > > /var/lib/snapd/snap/gtk-common-themes/1519 > > > /dev/loop792M 92M 0 100% > > > /var/lib/snapd/snap/gtk-common-themes/1535 > > > /dev/loop8 128K 128K 0 100% > > > /var/lib/snapd/snap/hello-world/29 > > > /dev/loop9 141M 141M 0 100% > > > /var/lib/snapd/snap/mathpix-snipping-tool/155 > > > /dev/loop10 141M 141M 0 100% > > > /var/lib/snapd/snap/mathpix-snipping-tool/195 > > > /dev/loop11 92M 92M 0 100% > > > /var/lib/snapd/snap/p3x-onenote/136 > > > /dev/loop12 81M 81M 0 100% > > > /var/lib/snapd/snap/p3x-onenote/154 > > > /dev/loop13 33M 33M 0 100% > > > /var/lib/snapd/snap/snapd/11107 > > > /dev/loop14 33M 33M 0 100% > > > /var/lib/snapd/snap/snapd/12704 > > > tmpfs3.2G 108K 3.2G 1% > > > /run/user/1000 > > > # > > > > You’re using 68 out of 69GB of your “/“ filesystem. (i.e the root > > filesystem). Several people have suggested ways to save some space, but I > > notice you are also using snaps, and they’re well known for taking up a lot > > of space because they retain multiple revisions of each app and dependency. > > > > I avoid snaps like the plague so I can’t tell you how to clean up space > > used by snapd. But I’m sure there’s an Ubuntu wiki that’ll help somewhere. > > Hear, hear! Snaps are nothing but trouble. > > I've seen old snaps consume all space or a server that formerly had > about 240 GB of free space. Thanks, Jeff: I have just removed all snaps! Paul ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Upgrade to F39: Disk Requirements: At least 5633 MB more space needed on the / filesystem.
On Tue, Nov 7, 2023 at 5:48 PM Jonathan Billings wrote: > > > Thanks, Peter: > > > > # df -h > > Filesystem Size Used Avail Use% Mounted on > > devtmpfs 4.0M 0 4.0M 0% /dev > > tmpfs 16G 194M 16G 2% /dev/shm > > tmpfs6.3G 1.7M 6.3G 1% /run > > /dev/mapper/fedora_localhost--live-root 69G 68G 0 100% / > > tmpfs 16G 36M 16G 1% /tmp > > /dev/sda1974M 280M 627M 31% /boot > > /dev/mapper/fedora_localhost--live-home 794G 397G 357G 53% /home > > /dev/loop0 128K 128K 0 100% > > /var/lib/snapd/snap/bare/5 > > /dev/loop256M 56M 0 100% > > /var/lib/snapd/snap/core18/2284 > > /dev/loop1 117M 117M 0 100% > > /var/lib/snapd/snap/core/14946 > > /dev/loop356M 56M 0 100% > > /var/lib/snapd/snap/core18/2745 > > /dev/loop4 165M 165M 0 100% > > /var/lib/snapd/snap/gnome-3-28-1804/161 > > /dev/loop5 165M 165M 0 100% > > /var/lib/snapd/snap/gnome-3-28-1804/198 > > /dev/loop666M 66M 0 100% > > /var/lib/snapd/snap/gtk-common-themes/1519 > > /dev/loop792M 92M 0 100% > > /var/lib/snapd/snap/gtk-common-themes/1535 > > /dev/loop8 128K 128K 0 100% > > /var/lib/snapd/snap/hello-world/29 > > /dev/loop9 141M 141M 0 100% > > /var/lib/snapd/snap/mathpix-snipping-tool/155 > > /dev/loop10 141M 141M 0 100% > > /var/lib/snapd/snap/mathpix-snipping-tool/195 > > /dev/loop11 92M 92M 0 100% > > /var/lib/snapd/snap/p3x-onenote/136 > > /dev/loop12 81M 81M 0 100% > > /var/lib/snapd/snap/p3x-onenote/154 > > /dev/loop13 33M 33M 0 100% > > /var/lib/snapd/snap/snapd/11107 > > /dev/loop14 33M 33M 0 100% > > /var/lib/snapd/snap/snapd/12704 > > tmpfs3.2G 108K 3.2G 1% > > /run/user/1000 > > # > > You’re using 68 out of 69GB of your “/“ filesystem. (i.e the root > filesystem). Several people have suggested ways to save some space, but I > notice you are also using snaps, and they’re well known for taking up a lot > of space because they retain multiple revisions of each app and dependency. > > I avoid snaps like the plague so I can’t tell you how to clean up space used > by snapd. But I’m sure there’s an Ubuntu wiki that’ll help somewhere. Thanks to all who have answered. The command dnf autoremove did the trick. (I am sending this message from F39.) Paul ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Upgrade to F39: Disk Requirements: At least 5633 MB more space needed on the / filesystem.
On Tue, Nov 7, 2023 at 4:57 PM Peter Boy wrote: > > >> > >> While running > >> > >> dnf system-upgrade download --releasever=39 > >> > >> to upgrade Fedora, I get the following error: > >> > >> Error Summary - > >> Disk Requirements: At least 5633 MB more space needed on the / filesystem. > >> > >> Could you please help me? > > > > Maybe I can delete something from the following, to free up space? > > > > # dir /boot > > config-6.5.8-200.fc38.x86_64 > > config-6.5.9-200.fc38.x86_64 > > efi > > extlinux > > grub2 > > initramfs-0-rescue-5cbe81aa795444b29a47ec1bf2b6dca1.img > > initramfs-5.14.9-200.fc34.x86_64.img > > initramfs-5.8.11-200.fc32.x86_64.img > > initramfs-6.5.8-200.fc38.x86_64.img > > initramfs-6.5.9-200.fc38.x86_64.img > > loader > > lost+found > > memtest86+x64.bin > > symvers-6.5.8-200.fc38.x86_64.xz > > symvers-6.5.9-200.fc38.x86_64.xz > > System.map-6.5.8-200.fc38.x86_64 > > System.map-6.5.9-200.fc38.x86_64 > > vmlinuz-0-rescue-5cbe81aa795444b29a47ec1bf2b6dca1 > > vmlinuz-6.5.8-200.fc38.x86_64 > > vmlinuz-6.5.9-200.fc38.x86_64 > > # > > > > Paul > > That may not help a lot. You need more space in / > > I guess, we need more information, e.g. the output of "df -h“, which Edition > at least. Thanks, Peter: # df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 4.0M 0 4.0M 0% /dev tmpfs 16G 194M 16G 2% /dev/shm tmpfs6.3G 1.7M 6.3G 1% /run /dev/mapper/fedora_localhost--live-root 69G 68G 0 100% / tmpfs 16G 36M 16G 1% /tmp /dev/sda1974M 280M 627M 31% /boot /dev/mapper/fedora_localhost--live-home 794G 397G 357G 53% /home /dev/loop0 128K 128K 0 100% /var/lib/snapd/snap/bare/5 /dev/loop256M 56M 0 100% /var/lib/snapd/snap/core18/2284 /dev/loop1 117M 117M 0 100% /var/lib/snapd/snap/core/14946 /dev/loop356M 56M 0 100% /var/lib/snapd/snap/core18/2745 /dev/loop4 165M 165M 0 100% /var/lib/snapd/snap/gnome-3-28-1804/161 /dev/loop5 165M 165M 0 100% /var/lib/snapd/snap/gnome-3-28-1804/198 /dev/loop666M 66M 0 100% /var/lib/snapd/snap/gtk-common-themes/1519 /dev/loop792M 92M 0 100% /var/lib/snapd/snap/gtk-common-themes/1535 /dev/loop8 128K 128K 0 100% /var/lib/snapd/snap/hello-world/29 /dev/loop9 141M 141M 0 100% /var/lib/snapd/snap/mathpix-snipping-tool/155 /dev/loop10 141M 141M 0 100% /var/lib/snapd/snap/mathpix-snipping-tool/195 /dev/loop11 92M 92M 0 100% /var/lib/snapd/snap/p3x-onenote/136 /dev/loop12 81M 81M 0 100% /var/lib/snapd/snap/p3x-onenote/154 /dev/loop13 33M 33M 0 100% /var/lib/snapd/snap/snapd/11107 /dev/loop14 33M 33M 0 100% /var/lib/snapd/snap/snapd/12704 tmpfs3.2G 108K 3.2G 1% /run/user/1000 # ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Upgrade to F39: Disk Requirements: At least 5633 MB more space needed on the / filesystem.
On Tue, Nov 7, 2023 at 4:46 PM Paul Smith wrote: > > While running > > dnf system-upgrade download --releasever=39 > > to upgrade Fedora, I get the following error: > > Error Summary - > Disk Requirements: At least 5633 MB more space needed on the / filesystem. > > Could you please help me? Maybe I can delete something from the following, to free up space? # dir /boot config-6.5.8-200.fc38.x86_64 config-6.5.9-200.fc38.x86_64 efi extlinux grub2 initramfs-0-rescue-5cbe81aa795444b29a47ec1bf2b6dca1.img initramfs-5.14.9-200.fc34.x86_64.img initramfs-5.8.11-200.fc32.x86_64.img initramfs-6.5.8-200.fc38.x86_64.img initramfs-6.5.9-200.fc38.x86_64.img loader lost+found memtest86+x64.bin symvers-6.5.8-200.fc38.x86_64.xz symvers-6.5.9-200.fc38.x86_64.xz System.map-6.5.8-200.fc38.x86_64 System.map-6.5.9-200.fc38.x86_64 vmlinuz-0-rescue-5cbe81aa795444b29a47ec1bf2b6dca1 vmlinuz-6.5.8-200.fc38.x86_64 vmlinuz-6.5.9-200.fc38.x86_64 # Paul ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Upgrade to F39: Disk Requirements: At least 5633 MB more space needed on the / filesystem.
Dear All, While running dnf system-upgrade download --releasever=39 to upgrade Fedora, I get the following error: Error Summary - Disk Requirements: At least 5633 MB more space needed on the / filesystem. Could you please help me? Thanks in advance, Paul ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Duplicated start menu entries
Dear All, I was playing with menulibre and alacarte, and now I have some duplicated start menu entries. Could you please help me? I am using XFCE on Fedora 38. Thanks in advance, Paul PS: I posted this on the XFCE mailing list two days ago, but nobody has answered. That is why I am now using Fedora list. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Feature request for --error-undefined-variables
On Mon, 2023-10-16 at 15:00 +, R. Diez wrote: > I would like to have a flag like "--error-undefined-variables" > instead, which would be the equivalent to Bash' option "set -o > nounset". This way, such programming errors cannot go undetected any > more. This has already been implemented in Git and will be available in the next release of GNU Make. >From the NEWS file for the next release: * New feature: Makefile warning reporting control A new option "--warn" controls reporting of warnings for makefiles. Actions can be set to "ignore", "warn", or "error". Two new warnings are reported: assigning to invalid variable names, and referencing invalid variable names (both set to "warn" by default), in addition to the existing warning for undefined variables (defaults to "ignore"). "--warn-undefined-variables" is deprecated, and is translated to "--warn=undefined-vars" internally. * New feature: Control warnings with the .WARNINGS variable In addition to --warn from the command line, which takes effect for make invoked recursively, warnings can be controlled only for the current instance of make using the .WARNINGS variable. The man page says: --warn[=ARG[,ARG]] Control warning reporting for makefiles. This option can appear multiple times. In case of conflicts, later settings override earlier settings. ARG can be an action; one of ignore, warn, or error to set the default action for all warnings, or it can be a specific warning: invalid-var (assigning to an invalid variable name), invalid-ref (referencing an invalid variable name), or un‐ defined-var (referencing an undefined variable). The behavior of each warning can be set by adding :action after the warning name. If an action is not specified the default is warn. If no ARG is provided the action for all warnings is warn. If no --warn option is provided the default action for invalid-var and invalid-ref is warn and the default action for undefined-var is ignore. --warn-undefined-variables A deprecated alternative for --warn=undefined-var. The user manual has more detail.
Re: MAKE BUG
On Fri, 2023-10-13 at 13:13 +0530, Nachiketa Gupta wrote: > Hi All, > MAKE version 3.8 > So my question is why does it always print -j independent of -j > value? > is some make.conf file located in our area which is overriding this > variable with -j? > I have also confirmed that with the 4.3 version it's working and > printing -j with value. Please don't post screenshots; instead please cut and paste the code into question as text. Thanks. The answer to your question is right in the question itself. The behavior you see (with just -j) is what you get when you run GNU Make 3.81 (there is no version "3.8" of GNU Make). The behavior you want (with the numeric extension to -j) is what you get when you run GNU Make 4.3. So, clearly there has been a change in behavior between 3.81 and 4.3. This change was introduced in GNU Make 4.2: https://git.savannah.gnu.org/cgit/make.git/tree/NEWS?id=4.2 https://git.savannah.gnu.org/cgit/make.git/tree/NEWS?id=4.2#n36
