Guillaume Rousse wrote:
> Also sprach Ralf Wildenhues:
>> This machinery is all present in automake.in (but not accessible from
>> outside). Sorry, I haven't worked on this more yet.
> Which basically there is no other solution without modyfing automake
> currently, right ?
>
> OK, I'll release camlimages in current state (after all, standard build
> works), and will try to deal with this later.
Here is a summary of three possibile strategies for dealing with nested
source tree, with object created with explicit make rules (by opposition
to automake-computed rules), taking an image tree for example, with the
following thumbnail creation rule:
SUFFIXES = .png .small.png
.png.small.png:
convert -geometry $(SMALL_WIDTH)x$(SMALL_HEIGHT) $< $@
1) create a makefile.am in each source tree subdirectory, using include
statement to avoid repeating rule
This way, automake will be aware of the tree structure:
.
|-- Makefile.am
|-- Makefile.inc
|-- subdir1
| `-- Makefile.am
`-- subdir2
`-- Makefile.am
2) use only one Makefile.am at top-level directory, but take cares of
checking if output directory exist in the rule:
.png.small.png:
dir=`dirname [EMAIL PROTECTED]; \
if [ ! -d $$dir ]; then \
mkdir -p $$dir; \
fi
convert -geometry $(SMALL_WIDTH)x$(SMALL_HEIGHT) $< $@
3) output everything at the top-level directory:
.png.small.png:
convert -geometry $(SMALL_WIDTH)x$(SMALL_HEIGHT) $< `basename [EMAIL
PROTECTED]
This is only possible if there is no name conflict, of course.
Basically, I'd say 1) provides better readability, 2) provides better
scalability for same result, and 3) offer both advantage for a slightlt
different result, with additional constraints. Am I correct there ?
