Path: ...!weretis.net!feeder6.news.weretis.net!feeder8.news.weretis.net!news.mixmin.net!aioe.org!Faqf6A55NG1s8DSVkh3L9A.user.46.165.242.75.POSTED!not-for-mail
From: Alain Ketterlin <alain@universite-de-strasbourg.fr.invalid>
Newsgroups: fr.comp.os.unix
Subject: Re: Make =?utf-8?Q?=C3=A9crase?= mes fichiers !
Date: Sun, 17 Oct 2021 16:14:23 +0200
Organization: =?utf-8?Q?Universit=C3=A9?= de Strasbourg
Message-ID: <87sfwz68n4.fsf@universite-de-strasbourg.fr.invalid>
References: <87fst657vq.fsf@universite-de-strasbourg.fr.invalid>
	<sk4qbg$7ld$1@cabale.usenet-fr.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Injection-Info: gioia.aioe.org; logging-data="1886"; posting-host="Faqf6A55NG1s8DSVkh3L9A.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux)
Cancel-Lock: sha1:KP0MUO73hkRnSfhvERlkttuuC6Q=
X-Notice: Filtered by postfilter v. 0.9.2
Bytes: 3290
Lines: 70


Je r=C3=A9ponds ici =C3=A0 (l'autre message de) Olivier pour garder un peu =
de
contexte.

Olivier Miakinen <om+news@miakinen.net> writes:

>> # --------
>> name: name.tab.o name.o
>>=20
>> name.tab.c: name.y
>> 	bison name.y
>> # --------

> Bon, d=C3=A9j=C3=A0 on pourrait arg=C3=BCer que ce n'est pas une bonne id=
=C3=A9e d'avoir
> deux fichiers sources qui ne diff=C3=A8rent que par une extension connue
> de make. Mais voyons plus loin.

On pourrait, mais d'une part c'est un projet o=C3=B9 j'ai plusieurs sources
yacc/bison et je suis all=C3=A9 au plus simple, d'autre part la r=C3=A8gle =
make
"%.y: %.c" est contraire aux conventions de yacc (qui produit par d=C3=A9fa=
ut
y.tab.c) ou de bison (qui produit %.tab.c). D'o=C3=B9 ma surprise.

>> [...]
>>=20
>> | yacc  name.y=20
>> | mv -f y.tab.c name.c
>> | cc    -c -o name.o name.c
>> | bison name.y
>> | ...
>
> Donc oui, c'est clairement une r=C3=A8gle implicite pour faire un fichier=
 .c
> =C3=A0 partir d'un fichier .y -- implicite puisque dans ton makefile tu ne
> d=C3=A9finis qu'une r=C3=A8gle avec bison et aucune avec yacc.
>
> Si tu veux conserver name.y et name.c comme deux fichiers *sources*
> ind=C3=A9pendants, alors je vois ceci :
>
> man make
> ...
>        -r, --no-builtin-rules
>             Eliminate  use of the built-in implicit rules.  Also clear
>             out the default list of suffixes for suffix rules.
> ...

Ben oui, mais les r=C3=A8gles implicites pour C sont bien pratiques (avec
CFLAGS etc.) J'ai finalement chang=C3=A9 mes conventions de nommage.

Je me demande si on ne pourrait pas imaginer une contrainte qui
emp=C3=AAcherait make d'utiliser une r=C3=A8gle implicite quand les pr=C3=
=A9requis sont
mentionn=C3=A9s explicitement dans une r=C3=A8gle avec une commande... Bref.

(Au passage, j'ai =C3=A9t=C3=A9 pi=C3=A9g=C3=A9 par une autre r=C3=A8gle im=
plicite, parce que
j'avais la r=C3=A8gle suivante :

name.lex.c: name.lex
	flex -o $@ $<

mais l=C3=A0 make m'indique une circularit=C3=A9, =C3=A0 cause de sa r=C3=
=A8gle "%: %.c". Ma
cible s'appelle maintenant name.dfa.c.)

Merci en tout cas pour ta r=C3=A9ponse.

-- Alain.