helpcontent2 | 2 +- solenv/gbuild/AllLangHelp.mk | 11 ++++++++++- solenv/gbuild/TargetLocations.mk | 1 + 3 files changed, 12 insertions(+), 2 deletions(-)
New commits: commit e5ad0150dc543ccbf3631ea57ad0919b3faa599b Author: Stephan Bergmann <[email protected]> Date: Wed Jun 6 09:45:58 2018 +0200 Updated core Project: help 5197a6b9def2e1886e3edab75517864272115089 (Partially) fix --with-help=html dependencies on .xhp files There are three rules in helpcontent2/CustomTarget_html.mk that process (with XSLT) all or some of the .xhp files in the helpcontent2/source/text/ tree (for en-US; or their translations in the workdir/HelpTranslatePartTarget/*/helpcontent2/source/text/ trees for other languages). Lists of all those .xhp files are defined in helpcontent2/AllLangHelp_*.mk (with gb_AllLangHelp_add_helpfiles), but the code in helpcontent2/CustomTarget_html.mk used `find` to assemble the relevant lists. That has two issues (at least for the en-US case operating on the untranslated helpcontent2/source/text/ files): For one, if the content of those .xhp files changes, the relevant XSLT processing is not re-run. For another, if .xhp files are added to or removed from the lists in helpcontent2/AllLangHelp_*.mk, the relevant XSLT processeing is not re-run, either. For the processing of translated .xhp files, there were already dependencies on those translated files in place. I assume (but have not really proved it) that those dependencies are already sufficient to cover both of the above issues. That only leaves the en-US case, operating on the untranslated files. The lists of .xhp files as defined in helpcontent2/AllLangHelp_*.mk (with "*" ranging over the various "modules": sbasic, scalc, schart, etc.) are now made available in gb_AllLangHelp_*_HELPFILES variables. The contents of those variables is used instead of `find` to pass the relevant .xhp files to the XSLT processings. (Needing some RESPONSEFILE and `xargs -n 1` boilerplate to feed individual files to the XSL processing without overflowing maximum command line lengths. Also, on Windows, var2file apparently writes CRLF line ends but the CR parts need to be filtered out again, and xargs problems must be worked around similar to df9edbcd2883cec2d0596133131cfbc220dee91f "Work around 'xargs: environment is too large for exec' errors on Windows".) However, those variables apparently cannot be used to specify dependencies for the three XSLT-processing rules. Presumably, the variables do not necessarily have their values assigned yet by the time the rules' dependencies are constructed (depending on the order in which .mk files are read?). So "dummy" gb_AllLangHelp_get_helpfiles_target targets are introduced, which depend on all the relevant .xhp files (and which get constructed during gb_AllLangHelp_add_helpfiles, just like the gb_AllLangHelp_*_HELPFILES variables), and which the XSLT-processing rules in turn depend on. That makes sure that the XSLT-processing rules are re-run when the content of .xhp files changes or when new .xhp files are added. However, the above still fails to re-run the XSLT-processing rules when .xhp files are removed. This is the helpcontent2 part of a commit spanning core and helpcontent2. Change-Id: I9a72c0f6837a8e13458a703fdecf7e5b0ef2076f Reviewed-on: https://gerrit.libreoffice.org/55364 Tested-by: Jenkins <[email protected]> Reviewed-by: Stephan Bergmann <[email protected]> diff --git a/helpcontent2 b/helpcontent2 index 3765355e41d0..5197a6b9def2 160000 --- a/helpcontent2 +++ b/helpcontent2 @@ -1 +1 @@ -Subproject commit 3765355e41d02ee3e5f64ef6ece336641553e7c7 +Subproject commit 5197a6b9def2e1886e3edab75517864272115089 commit ec8edaa3e0b42158f17e540895d5422f91a99fbe Author: Stephan Bergmann <[email protected]> Date: Wed Jun 6 09:45:14 2018 +0200 (Partially) fix --with-help=html dependencies on .xhp files There are three rules in helpcontent2/CustomTarget_html.mk that process (with XSLT) all or some of the .xhp files in the helpcontent2/source/text/ tree (for en-US; or their translations in the workdir/HelpTranslatePartTarget/*/helpcontent2/source/text/ trees for other languages). Lists of all those .xhp files are defined in helpcontent2/AllLangHelp_*.mk (with gb_AllLangHelp_add_helpfiles), but the code in helpcontent2/CustomTarget_html.mk used `find` to assemble the relevant lists. That has two issues (at least for the en-US case operating on the untranslated helpcontent2/source/text/ files): For one, if the content of those .xhp files changes, the relevant XSLT processing is not re-run. For another, if .xhp files are added to or removed from the lists in helpcontent2/AllLangHelp_*.mk, the relevant XSLT processeing is not re-run, either. For the processing of translated .xhp files, there were already dependencies on those translated files in place. I assume (but have not really proved it) that those dependencies are already sufficient to cover both of the above issues. That only leaves the en-US case, operating on the untranslated files. The lists of .xhp files as defined in helpcontent2/AllLangHelp_*.mk (with "*" ranging over the various "modules": sbasic, scalc, schart, etc.) are now made available in gb_AllLangHelp_*_HELPFILES variables. The contents of those variables is used instead of `find` to pass the relevant .xhp files to the XSLT processings. (Needing some RESPONSEFILE and `xargs -n 1` boilerplate to feed individual files to the XSL processing without overflowing maximum command line lengths. Also, on Windows, var2file apparently writes CRLF line ends but the CR parts need to be filtered out again, and xargs problems must be worked around similar to df9edbcd2883cec2d0596133131cfbc220dee91f "Work around 'xargs: environment is too large for exec' errors on Windows".) However, those variables apparently cannot be used to specify dependencies for the three XSLT-processing rules. Presumably, the variables do not necessarily have their values assigned yet by the time the rules' dependencies are constructed (depending on the order in which .mk files are read?). So "dummy" gb_AllLangHelp_get_helpfiles_target targets are introduced, which depend on all the relevant .xhp files (and which get constructed during gb_AllLangHelp_add_helpfiles, just like the gb_AllLangHelp_*_HELPFILES variables), and which the XSLT-processing rules in turn depend on. That makes sure that the XSLT-processing rules are re-run when the content of .xhp files changes or when new .xhp files are added. However, the above still fails to re-run the XSLT-processing rules when .xhp files are removed. This is the core part of a commit spanning core and helpcontent2. Change-Id: I0cb5f83097db17fbd7ae8b528418b0ec24bee602 Reviewed-on: https://gerrit.libreoffice.org/55363 Tested-by: Jenkins <[email protected]> Reviewed-by: Stephan Bergmann <[email protected]> diff --git a/solenv/gbuild/AllLangHelp.mk b/solenv/gbuild/AllLangHelp.mk index eef0f8b24d70..18fe1956b71c 100644 --- a/solenv/gbuild/AllLangHelp.mk +++ b/solenv/gbuild/AllLangHelp.mk @@ -35,7 +35,7 @@ ifeq ($(ENABLE_HTMLHELP),) $(call gb_Output_announce,$*,$(false),ALH,5) endif $(call gb_Helper_abbreviate_dirs,\ - rm -f $(call gb_AllLangHelp_get_target,$*) \ + rm -f $(call gb_AllLangHelp_get_target,$*) $(call gb_AllLangHelp_get_helpfiles_target,$*) \ ) # gb_AllLangHelp_AllLangHelp__one_lang module lang helpname @@ -86,9 +86,18 @@ define gb_AllLangHelp_add_helpfiles $(foreach lang,$(gb_HELP_LANGS),\ $(call gb_HelpTarget_add_helpfiles,$(call gb_AllLangHelp__get_helpname,$(1),$(lang)),$(2)) \ ) +ifneq ($(ENABLE_HTMLHELP),) +gb_AllLangHelp_$(1)_HELPFILES += $(addsuffix .xhp,$(2)) +$(call gb_AllLangHelp_get_helpfiles_target,$(1)): $(addprefix $(SRCDIR)/,$(addsuffix .xhp,$(2))) +endif endef +ifneq ($(ENABLE_HTMLHELP),) +$(call gb_AllLangHelp_get_helpfiles_target,%): + touch $@ +endif + # Add additional localized file(s) to the help pack. # # gb_AllLangHelp_add_localized_files module basedir file(s) diff --git a/solenv/gbuild/TargetLocations.mk b/solenv/gbuild/TargetLocations.mk index 4911b1b8c137..7f658d9c608c 100644 --- a/solenv/gbuild/TargetLocations.mk +++ b/solenv/gbuild/TargetLocations.mk @@ -34,6 +34,7 @@ gb_UnoApi_get_target = $(INSTROOT)/$(if $(filter udkapi,$(1)),$(LIBO_URE_MISC_FO gb_AutoInstall_get_target = $(WORKDIR)/AutoInstall/$(1) gb_AllLangHelp_get_target = $(WORKDIR)/AllLangHelp/$(1) +gb_AllLangHelp_get_helpfiles_target = $(WORKDIR)/AllLangHelp/$(1).helpfiles gb_AllLangPackage_get_target = $(WORKDIR)/AllLangPackage/$(1) gb_AllLangMoTarget_get_target = $(WORKDIR)/AllLangMo/$(1) gb_AsmObject_get_target = $(WORKDIR)/AsmObject/$(1).o _______________________________________________ Libreoffice-commits mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
