[FFmpeg-devel] [PATCH] web: Copy FFmpeg Logo by Makefile instead of cronjob

Thilo Borgmann thilo.borgmann at googlemail.com
Tue Apr 17 11:41:07 CEST 2012

Am 16.04.12 23:57, schrieb Reimar Döffinger:
> On 16 Apr 2012, at 23:43, Thilo Borgmann <thilo.borgmann at googlemail.com>
> wrote:
>> Am 16.04.12 21:51, schrieb Reimar Döffinger:
>>> On 16 Apr 2012, at 17:36, Thilo Borgmann <thilo.borgmann at googlemail.com> 
>>> wrote:
>>>> Am 14.04.12 18:05, schrieb Reimar Döffinger:
>>>>> On Sat, Apr 14, 2012 at 11:46:03AM +0200, Michael Niedermayer wrote:
>>>>>> On Wed, Apr 11, 2012 at 12:50:34PM +0200, Thilo Borgmann wrote:
>>>>>>>> this will update teh file even if it matches, this breaks
>>>>>>>> caching of the logo
>>>>>>> Updated Patch attached.
>>>>>> from a quick look, its ok maybe reimar can double check ?
>>>>> I don't see any real issues with it. Though if you're pedantic
>>>>> there's a questions whether "test -r" is the best condition, copying
>>>>> over the file to my knowledge won't fix any permissions which is why
>>>>> I went with -f originally. I don't think it really matters, when it
>>>>> makes a different things are already seriously broken anyway and will
>>>>> need manual intervention.
>>>> I don't really get it.
>>>> "test -r" or "test -f" - what does that have to do with fixing 
>>>> permissions?
>>> What is the point of overwriting the file when  the problem is that the
>>> file exists but is not readable, when that will be the case afterward
>>> still?
>>> That's why I chose -f since it avoids pointlessly copying, but as said I 
>>> think it doesn't matter really.
>> I might misunderstand test, but -f would pointlessly copy if the file is
>> not readable. -r would at least not do that but could still fail if the
>> file is not writable. So if we check the file, we should have to check r&w
>> permissions.
> test -f will fail (and thus cause the copy) when the file is not a regular
> file (so -e might be better). test -r will fail when the file is not
> readable, including when it exists but does not have read permissions.
>> What do you think about "cp -f" to retain permissions of the
>> previous/initial file? Useful in my eyes if the git repo creates files with
>> different permission than we want for the logo file.
> I don't know where you got your understanding of the -f option from, but my
> manpage certainly does not match it. If the file is writeable -f or not does
> not make a difference, permissions remain unchanged. Only if write
> permissions are missing does the behaviour differ: without -f it will fail,
> with it will delete the file and potentially recreate it with new permissions
> (I presume with the default permissions based on umask). 

cp seems to differ actually...

However, patch applied.


-------------- next part --------------
From 57ab223b421e83f75761bd7d77098bbf5fd5ea84 Mon Sep 17 00:00:00 2001
From: Thilo Borgmann <thilo.borgmann at googlemail.com>
Date: Tue, 17 Apr 2012 11:37:53 +0200
Subject: [PATCH] web: Let the Makefile copy the website logo according to src/logik.

 Makefile |   14 ++++++++++++--
 1 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index 9c8110d..dbc8dd4 100644
--- a/Makefile
+++ b/Makefile
@@ -7,8 +7,15 @@ TARGETS = $(addsuffix .html,$(addprefix htdocs/,$(SRCS))) htdocs/main.rss
 PAGE_DEPS = src/template_head1 src/template_head2 src/template_footer
+DATE := $(shell date +%m%d)
-all: $(TARGETS)
+ifneq ($(wildcard src/logik/$(DATE)-standard),)
+	LOGO_SRC := htdocs/FFmpeg_standard.png
+	LOGO_SRC := $(wildcard src/logik/$(DATE).png)
+all: htdocs/ffmpeg-logo.png $(TARGETS)
 	rm -f $(TARGETS)
@@ -35,5 +42,8 @@ X' >> $@
 	echo '</channel>' >> $@
 	echo '</rss>' >> $@
+htdocs/ffmpeg-logo.png: $(LOGO_SRC)
+	test -z $< || cmp $< $@ || cp $< $@
+	test -e $@ || cp htdocs/FFmpeg_standard.png $@
-.PHONY: all clean
+.PHONY: all clean htdocs/ffmpeg-logo.png

More information about the ffmpeg-devel mailing list