Hoi Paul,
>>>> Er zit een rule "upstream" in debian/rules van een package wat ik graag
>>>> wil uitvoeren. Echter als ik "./debian/rules upstream" doe dan zie ik
>>>> alleen "make: 'upstream' is bijgewerkt", terwijl het niets gedaan heeft
>>>> (het zou localisatie-bestanden moeten downloaden). Als ik er "echo
>>>> hallo" bij zet, dan zie ik dat ook niet uitgevoerd worden. Als ik mijn
>>>> eigen rule maak met als inhoud "echo hallo" dan gaat het wel goed.
>>>>
>>>> Wat doe ik verkeerd?
>>> Waarschijnlijk bestaat er al een (leeg) bestand genaamd 'upstream' in de
>>> debian directory. Dat bestand moet je even weggooien.
>>
>> Dat moet zijn: in de top-level directory van het pakket (de directory van
>> waaruit je 'debian/rules upstream' aaroept), niet in de debian/
>> direcrtory. Mijn excuses.
>
> Daar staat inderdaad een directory "upstream", en als ik die verwijder
> dan gaat hij meer doen. Toch gaat het niet goed.
>
> Als ik kijk naar de code dan wil hij deze directory leegmaken en dan
> opnieuw vullen met te downloaden bestanden. Toch weigert hij iets te
> doen als deze directory er is. Ik snap de logica niet helmaal.
>
> Dit is de originele code:
> -----------------
> upstream:
> for XPI in $(wget
> http://mirror.switch.ch/ftp/mirror/mozilla/calendar/sunbird/releases/$(VERSION)/langpacks
> -O - | grep ".xpi</a>" | awk -F\" '{ print $10 }'); \
> do \
> rm -f upstream/$(basename $$XPI); \
> wget
> http://releases.mozilla.org/pub/mozilla.org/calendar/sunbird/releases/$(VERSION)/langpacks/$$XPI;
> \
> done
> -----------------
>
> Dit is wat ik krijg als ik het uitvoer zonder upstream directory:
> -------------
> paul@server2:~/sources/icowl2/iceowl-l10n-0.8+debian$ ./debian/rules
> upstream
> for XPI in ; \
> do \
> rm -f upstream/$XPI; \
> wget
> http://releases.mozilla.org/pub/mozilla.org/calendar/sunbird/releases/0.8/langpacks/$XPI;
> \
> done
> --------------
>
> Terwijl die eerste regel het wel doet (als ik $(VERSION) vervang door
> 0.8). Wellicht doet de code het gewoon niet, ahum.
De code is inderdaad verre van correct. Ten eerste zal het target niks
doen als de directory bestaat. Het target heeft geen dependencies, dus als
het target bestaat, beschouwt Make het target als 'up to date'. Maar als
de directory niet bestaat, dan is er ook geen code om hem aan te maken.
Ten tweede missen er een aantal $$ escapes, waardoor Make variabelen
probeert te expanden, die eigenlijk door de subshell moeten worden geexpand:
for XPI in $(wget ...
moet zijn
for XPI in $$(wget ...
En:
awk -F\" '{ print $10 }'
moet zijn:
awk -F\" '{ print $$10 }'
En
$(basename $$XPI)
moet zijn:
$$(basename $$XPI)
Ten derde probeert het script eventuele bestaande bestanden te rm'en uit
de directory 'upstream', maar downloadt ze vervolgens naar de huidige
directory. Dat klopt ook niet.
Kortom: deze code is zeker niet getest door de auteur, want hij klopt van
geen kant.
En tenslotte nog een opmerking: ik vind het parsen van HTML door een regel
te splitten op aanhalingstekens en vervolgens het 10e veld te pakken echt
te smerig voor woorden. Maar dat terzijde.
>>>> Ik vraag me ook af wat een naampje met "$" of "$$" ervoor precies doet,
>>>> en waarom zoveel regels eindigen op een backslash, alsof alles op 1
>>>> regel moet (loops e.d.).
>>> Een $ geeft aan dat het om een variabele gaat; een Make target kan ook een
>>> variabele zijn. Een $$ is een geescapete $, dus daarmee kun je het $ teken
>>> doorgeven naar een commando.
>
> OK, bedankt.
>
>>> Omdat Make alle commando's in een aparte sub-shell uitvoert, is het
>>> noodzakelijk, dat alle commando's die in dezelfde subshell _moeten_ worden
>>> uitgevoerd (zoals loops) op dezelfde regel staan. Vandaar de backslashes.
>>>
>>> Make is een ingewikkelde tool. Zie
>>> http://www.gnu.org/software/make/manual/make.html voor de manual.
>
> Dat ziet er bruikbaar uit. Bedankt!
Groeten,
Martijn.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature