Opinions on automating the creation of the IMAGEFILES
via IMAGEFILES=$(shell find ..) vs. removing the macro completely?
I figure if automated it's no longer a maintenance issue, and
retain the dependency that rebuilds docs when a doc image changes.
Could be useful if we ever automate doc creation.
If it weren't for the automation with find(1), I'd be all for
removal of the macro, as manual maintenance is bad, given
there's no feedback for omissions.
Greg Ercolano wrote:
> Albrecht Schlosser wrote:
>> Yes, I'd say, let's remove 'em all.
>> +1 for removing the dependencies and shorten docs/Makefile.
>> Did I overlook anything ?
>
> I agree; I'm for removing it completely, as we currently
> don't seem to have a need for it. We can always add it later.
>
> And right, the only thing they seem capable of is to detect
> if the html/pdf docs need to be rebuilt if an image was changed.
>
> It might be useful if, in the future, we had an automated system
> for updating the docs on the website. (But this currently seems to be a
> manual process)
>
> If that were the case, I'd suggest automating the construction
> of the macro with the following gnu make command:
>
> IMAGEFILES=$(shell find $(SRC_DOCDIR) -name '*.png' -o -name '*.jpg')
>
> This uses 'find' to populate the list of IMAGEFILES. Regarding
> its use over ls(1):
>
> (a) 'find' ensures a /recursive/ search, since as we learned a week
> or so ago, doxygen will recursively search for an "\image" if it
> doesn't find it in the top level dir.
>
> (b) searching only for *.png and *.jpg files since those are the
> only file formats that work consistently for both html and latex
> constructions. This also prevents unwanted files like .svn/* and
> *.svn-base from getting into the list.
>
> The overhead of the above command is fairly negligible, so maybe
> that's the best solution.
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
