Rearrangement of the HTML docs build rules

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Rearrangement of the HTML docs build rules
Дата
Msg-id 200907132304.59098.peter_e@gmx.net
обсуждение исходный текст
Ответы Re: Rearrangement of the HTML docs build rules  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
I have been looking at getting rid of the way we currently ship the 
documentation as a tarball within the tarball.

The first issue I encountered is that when you ship prebuilt files in a 
tarball, you want to make sure the make dependencies are correctly satisfied.   
For example, we prebuild gram.c from gram.y in a way that it doesn't get 
rebuild at the user's site.

This currently doesn't work well with the HTML docs.  You can run "make html" 
repeatedly, and it will rebuild the documentation every time.  This is of 
course the ancient problem with the index build requiring two runs.

I think I have finally figured out a way to do this correctly now.  The 
problem we've had with all previous solutions is that we have used the same 
file name, such as HTML.index or bookindex.sgml, to mean different things at 
different stages of the build, and make can't distinguish that.  The solution 
I have implemented is that

- The first jade run produces HTML.index, but does not require bookindex.sgml 
at all.

- The second jade run includes bookindex.sgml, but does not recreate 
HTML.index.

That way, when you change an sgml file, jade is run twice and at the end all 
dependencies are satisfied.

When you run one of the print format targets, only the first jade run is run, 
then the print target-specific commands.  If an HTML build has completed 
previously, the first jade run is skipped because the dependencies have 
already been satisfied.

The draft and check targets for quick builds and syntax verification are still 
there.

Patch attached.

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: Alpha release process
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Rearrangement of the HTML docs build rules