Revised: -24 March 2023
+Revised: +2 November 2024
These instruction assume you going to keep the issues lists source files in a directory named "issues", -and the issues lists generated HTML files in a directory named "issues-gh-pages".
--+Keeping the source files and generated HTML files in separate directories -falls out from the GitHub automatic web page approach: files in a branch named "gh-pages" -are automatically published by GitHub as web pages.
-
These instructions assume you keep the issues lists source files in a directory named issues.
+Each issue is stored in an XML file.
+The code in src generates the HTML issues lists from the XML sources.
+When changes to the XML files are pushed to the GitHub repository an automated
+GitHub Actions workflow
+generates new HTML files and commits them to the gh-pages branch.
+The content of the gh-pages branch is automatically deployed
+to https://cplusplus.github.io/LWG/.
+
std::filesystem supports Windows, and no additional -lstdc++fs linker option is needed)..bat scripts, or
- a POSIX environment is a prerequisite to use the equivalent .sh
- scripts..bat scripts;
+ a POSIX environment is a prerequisite to use the equivalent make
+ commands.-cd path-to-where-you-want-to-keep-this-stuff git clone git@github.com:cplusplus/LWG.git issues -git clone -b gh-pages git@github.com:cplusplus/LWG.git issues-gh-pages -cd issues -mkdir mailing+
Using recent versions of Git the second git clone command
-can be replaced by adding a new "worktree" that shares the repository metadata
-with the initial clone:
--git -C issues worktree add -b gh-pages ../issues-gh-pages origin/gh-pages -
This has the advantage of only cloning the repo once, -which saves time, bandwidth and disk space.
- +
+The commands shown below assume you are in the issues directory
+that contains the git repository cloned by the command above.
+
+The repository contains a Makefile that has recipes for
+building the software (make pgms),
+updating the meta-data (make new-papers etc.),
+and regenerating the HTML lists (make lists).
+
Do this after the initial setup, and then again whenever the source
-code (in issues/src) changes.
+If you can't use make then the steps are a little more manual:
+
-+cd issues -bin\build_pgms-
cd issues +mkdir mailing +bin\build_pgms +bin\build_lists ++
+You will need to re-run bin\build_pgms
+whenever the source code (in issues/src) changes.
+(This isn't needed when using make because the makefile
+will automatically do make pgms as a prerequisite of
+make lists.)
+
There is one source file per issue, in issues/xml. The file
-issues/xml/lwg-template.xml can be used as a template to start a
-new issue. Use any text editor to edit the files.
issues/xml/lwg-template.xml is a template for a
+new issue.
Commit files locally as you update them:
--cd issues\xml -edit-as-needed -git commit -a -m"your commit message here"-
Verify your changes had the desired effect by regenerating the -issues lists and inspecting your changes:
---cd issues -bin\build_lists+# edit the XML files or add new XML files +# ... +# stage the edited XML files (and any new ones) to be committed: +git add xml/issues*.xml +git commit -m "your commit message here"
Once you are happy with your changes, push them up to the GitHub +
Verify your changes had the desired effect by regenerating the
+issues lists and inspecting your changes, by running
+make lists (or bin\build_lists on Windows).
+
Once you are happy with your changes, push them up to the GitHub public repository:
-cd issues -git push+git push
New versions of the issues lists will be automatically published online.
@@ -155,7 +165,8 @@bin/lists revision history to print the new revision history.make history (or equivalently, bin/lists revision history)
+ to print the new revision history.<revision_history> tag