Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Convert manual to GAPDoc #9

Open
olexandr-konovalov opened this issue Sep 16, 2018 · 1 comment
Open

Convert manual to GAPDoc #9

olexandr-konovalov opened this issue Sep 16, 2018 · 1 comment

Comments

@olexandr-konovalov
Copy link
Member

Keeping gapmacro-based manual has some inconveniences when one uses ReleaseTools. First, I can not publish a release from any place, since it has a relative path to gapmacro.tex. Second, symlinking the clone into gap/pkg did not help. So I had to make a new clone of the repository. Third, inside that clone I had to recreate gh-pages subdirectory with:

cd modisom
git clone [email protected]:gap-packages/modisom.git gh-pages
cd gh-pages
git fetch origin gh-pages
git checkout gh-pages

With GAPDoc, none of these steps would be needed...

@olexandr-konovalov olexandr-konovalov changed the title Switch to GAPDoc Convert manual to GAPDoc Sep 16, 2018
@fingolfin
Copy link
Member

You can publish a location from (almost) any place, by placing a symlink to GAP's doc dir into a suitable place (i.e., such that gapmacro.tex is found). I rely on that all the time in my local setup. No need for a new clone.

But if you make a new clone, then yeah, you need to again clone gh-pages, as described in the GitHubPagesForGAP README. But release should produce an error if one forgets to.

BTW, even with GAPDoc, one has to be very careful if one builds the package outside the GAPROOT, as there is a risk that one ends up with absolute paths in the generated HTML, namely for links to documentation in other packages, if one has any of those. I think we applied various tricks to mitigate that in AutoDoc, so if you use AutoDoc in your makedoc.g, it's indeed usually OK; but I still check for absolute paths like that in the ReleaseTools, precisely because they have a tendency to creep in again if one is no careful

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants