On Sat, 2022-09-10 at 23:12 +0300, Fosil Crypto wrote:
> ubuntu@ip-172-31-95-154:~$ make ncdu gcc git jq chrony liblz4-tool -y
> make: invalid option -- 'y'
This is not a bug.
You are just invoking make incorrectly.
On Fri, 2022-03-18 at 21:12 +, Lahfa Samy wrote:
> I've reported this bug anonymously :
> https://savannah.gnu.org/bugs/index.php?62200 and would like to
> receive updates/comments on it by mail on my Savannah account, I
> don't know if the bug report could be assigned to me or the "posted
> b
> I found a bug
If you have, then it's more likely in the documentation for this "Oyster River
Project" than in the code of the Oyster River Project itself, let alone Gnu
Make.
> /bin/bash: activate: No such file or directory
That looks like the kind of problem you get when one of Python's "vi
On Wed, Mar 3, 2021 at 1:00 PM Goran V. wrote:
> Am Mittwoch, den 03.03.2021, 15:41 -0500 schrieb Paul Smith:
> > If by "a feature like that" you mean a way to create multiple pattern
> > rules with a single rule definition in the makefile, then obviously
> > this would require some new syntax bu
On Wed, 2021-03-03 at 22:00 +0100, Goran V. wrote:
> Am Mittwoch, den 03.03.2021, 15:41 -0500 schrieb Paul Smith:
> Yes, that is what I mean with "a feature like that". But I must say
> that I'm in no position to propose a patch as make is huge,
> http://git.savannah.gnu.org/cgit/make.git/tree/ .
Am Mittwoch, den 03.03.2021, 15:41 -0500 schrieb Paul Smith:
> If by "a feature like that" you mean a way to create multiple pattern
> rules with a single rule definition in the makefile, then obviously
> this would require some new syntax but assuming that syntax existed I
> don't see why it would
On Wed, 2021-03-03 at 21:32 +0100, Goran V. wrote:
> Maybe I was wrong to call this a bug but would a feature like that
> break anything?
If by "a feature like that" you mean a way to create multiple pattern
rules with a single rule definition in the makefile, then obviously
this would require som
Maybe I was wrong to call this a bug but would a feature like that
break anything?
Am Mittwoch, den 03.03.2021, 13:55 -0500 schrieb Paul Smith:
> On Wed, 2021-03-03 at 17:31 +0100, Goran V. wrote:
> > $(BUILD)/$(FRONTEND)/%.html \
> > $(BUILD)/$(FRONTEND)/%.js \
> > $(BUILD)/$(FRONTEND)/%.css \
On Wed, 2021-03-03 at 17:31 +0100, Goran V. wrote:
> $(BUILD)/$(FRONTEND)/%.html \
> $(BUILD)/$(FRONTEND)/%.js \
> $(BUILD)/$(FRONTEND)/%.css \
> $(BUILD)/$(FRONTEND)/%.svg \
> $(BUILD)/$(FRONTEND)/%.ico:
> @echo -n "$(FRONTEND) - building $@"
> @$(MD) $(BUILD)/$(FRONTEND)
>
On Sun, 2017-03-19 at 01:51 +, Alejandro García Vallejo wrote:
> bar: $(@:%r=foo%z)
> @echo End
>
> foobaz:
> @echo The
>
> """
> GNU Make Output:
> End
>
> Make fails to read $@ (aka, it's empty).
That's not a bug; that's defined behavior. From the GNU make manual:
https:
On Tue, 2014-08-12 at 14:48 +0800, clo...@gmail.com wrote:
> [root@localhost ~]# make --help
> -C DIRECTORY, --directory=DIRECTORY
> “在执行钱先切换到 DIRECTORY 目录。 ”
>
> should be
>
> “在执行前先切换到 DIRECTORY 目录。 ”
Hi;
Translations for GNU projects, including GNU make, are handled by the
Translation Pro
On Tue, 2013-01-29 at 14:42 +0100, Liang, Jian wrote:
> Make cannot handle the word or path that contains space.
You're right. The syntax of makefiles precludes this, and no version of
make supports it.
https://savannah.gnu.org/bugs/?712
___
Bug-mak
On Wed, 25 Apr 2012 20:30:41 -0400, Paul Smith wrote:
On Thu, 2012-04-26 at 00:19 +, Christophe Poncy wrote:
I have a have a bug during the compile phase of my Funtoo GNU/Linux
box. I was trying to emerge the 'boot-update' package, it seems
there
is a problem for compiling one of its depen
On Thu, 2012-04-26 at 00:19 +, Christophe Poncy wrote:
> I have a have a bug during the compile phase of my Funtoo GNU/Linux
> box. I was trying to emerge the 'boot-update' package, it seems there
> is a problem for compiling one of its dependency (lzo ).
[...]
> >>> Compiling source in
>
That's not a bug in make. It's a bug in whatever called make. You'd have to
take that up with whoever maintains, what, lzo? They seem to have done:
martind@whitewater:~$ make -j7-l7
make: the `-j' option requires a positive integral argument
Usage: make [options] [target] ...
When they probab
PS> however, and so I wouldn't expect people to think that messages to
PS> that list would become bug reports and automatically acknowledged, a
PS> la Debian's BTS etc.
Anyways from all the GNU man pages (but not exactly make's, true, but we
just remember bug-make@gnu.org anyway and wouldn't check
On Thu, 2011-04-14 at 07:28 +0800, jida...@jidanni.org wrote:
> I noticed that when submitting bugs to bug-*@gnu.org, unlike other bug
> submission by mail systems, e.g., Deb bugs of Debian, the user receives
> no cheery auto reply acknowledging the bug was ever even received and
> didn't go into a
On Thu, 2011-04-14 at 08:57 +0800, jida...@jidanni.org wrote:
> > "PS" == Paul Smith writes:
> PS> If you want a bug report to be filed and acknowledged, then you want:
> PS> https://savannah.gnu.org/bugs/?func=additem&group=make
> Thanks for answering! Well that's not the advertised way to su
> "PS" == Paul Smith writes:
PS> If you want a bug report to be filed and acknowledged, then you want:
PS> https://savannah.gnu.org/bugs/?func=additem&group=make
Thanks for answering! Well that's not the advertised way to submit bugs.
You advertise bug-*@gnu.org.
PS> The FSF does not use an em
I'm not sure I've understood. Perhaps rewording the second stanza like
this would address your concern?
"However, if you use the value $(objects) in a target or prerequisite,
wildcard expansion will take place there. If you use the value
$(objects) in a command, the shell may perform wildcard ex
A quick google for the error message turned up a fourth line, saying:
!!! If you need support, post the topmost build error, NOT this status message.
However, this list is for bugs in gnu make and your problem is far more likely
to be with something gentoo-specific. We don't know anything about
%% "Sandeep Nema" <[EMAIL PROTECTED]> writes:
sn> has been set in any way, including to the empty value
OK.
sn> You mentione in your previous answer that "?:" is not supported
sn> syntax, shouldn't it give any kind of error if its used in the
sn> makefile.
Just because the syntax doesn
please see my response/clarification below in bold with >
>>> "Paul D. Smith" <[EMAIL PROTECTED]> 01/05/04 10:08AM >>>
%% "Sandeep Nema" <[EMAIL PROTECTED]> writes:
sn> GNU make version: 3.80
sn> O/S: AIX 5.0
sn> We used "?:" macro substitution on tru64 platform with their
make, and
%% "Sandeep Nema" <[EMAIL PROTECTED]> writes:
sn> GNU make version: 3.80
sn> O/S: AIX 5.0
sn> We used "?:" macro substitution on tru64 platform with their make, and
sn> it works as following:
sn> X= $(EXCLUDE_X?:$(TMP_ADD_X))
sn> in the above if EXCLUDE_X is defined then X will be e
sorry about incomplete bug-report. Following are the details and further
questions.
GNU make version: 3.80
O/S: AIX 5.0
We used "?:" macro substitution on tru64 platform with their make, and
it works as following:
X= $(EXCLUDE_X?:$(TMP_ADD_X))
in the above if EXCLUDE_X is defined then X will be
%% "Sandeep Nema" <[EMAIL PROTECTED]> writes:
sn> In one of my makefile, I have following conditional syntax:
sn> ADDONS_DB_C = $(EXCLUDEFWKLIB?:$(TMP_ADDONS_DB_C))
sn> This gives me an error for MACRO SUBSTITUTION
First, this is not a proper bug report. Whenever you report a bug yo
%% Regarding Bug report & solution: make-3.80: Win32 linking error.; you
%% wrote:
n> It seems that script for assembling binaries of make-3.80 GNU make
n> utility for Win32 platform is incorrect.
This problem has been reported and fixed, and the fix will be available
in the next version of G
Hi,
You didn't send the full makefile, since the includes are missing.
Make apparently is considering the line "$(QuellP)/CnGET.h" a command to be
executed, where CnGET.h probably doesn't have execute permissions.
Look for the _exact_ definitions of variables like 'QuellP' and 'StreaP'
(including
Hi, I have a problem with one single line in a Make-File that I cannot
figure out at all. The problem is the same under version 3.77 and
3.79.1 under Linux.
The errro message is as follows:
make: execvp: ../CnGET.h: Keine Berechtigung
make: *** [../CnGET.h] Fehler 127
The version info:
GNU Mak
Hi, thanks for your reaction.
I understand that the most sensible thing for us to do is to upgrade. I
will do so and see whether the problem persists.
More later,
best regards Willi Doeringer
On Mon, 16 Dec 2002, Johan Bezem wrote:
> Please keep the mails on the list (reply-to set).
>
> To star
Please keep the mails on the list (reply-to set).
To start with, I just need the regular stdout from a normal call to make,
using the problematic version, possibly with a binary correct (as
attachment) version of the problematic makefile. If I need more, I'll shout.
But then again: make version 3
The makefile looks quite normal and simple to me. Executing the *.h file
could have resulted from:
- a missing/extraneous tab in the wrong place, or
- a missing/extraneous line continuation character.
Otherwise, please provide the makefile that produces the error (as this one
apparently is not), a
%% Francis Grolemund <[EMAIL PROTECTED]> writes:
fg> In any case, we ran into a subtle bug that was partially caused by
fg> our environment and how we've used gnumake, but I figured that
fg> since its such a pain in the ass, you guys may want to know about
fg> it. The problem is only occ
I believe this is an instance of a problem I've fixed for the next
version of GNU make, which should be appearing fairly soon.
If you like I can add you to the pretest list, if you want to try it and
see if it solves your problem.
--
-
34 matches
Mail list logo
