Bugfixes - Githubissues

Sp3EdeR commented 4 years ago

Changes:

Fixed Windows-specific external application command-lines https://github.com/copperspice/doxypress/issues/25
Fixed the breadcrumb index being one-off when using a main page, causing the navtree to be incorrect https://github.com/copperspice/doxypress/issues/27
Removed markdown heading index building; commentscan.cpp / addSection() does it correctly instead https://github.com/copperspice/doxypress/issues/29

It would mean very much if you could integrate this and provide a new build quickly (since I'm not able to create a proper build it seems). My company needs these fixes a lot.

Sp3EdeR commented 4 years ago

I fixed further stability bug fixes in this pull request for which I did not open any issue tickets...

agserm commented 4 years ago

Looked at 1c133e3, and it looks good. Cherry-pick of this commit is in our queue, will be completed next week. We will be reviewing the other commits in this PR shortly. Thanks for your contribution.

agserm commented 4 years ago

Thanks for your contributions in this PR. We took the changes that were simple to code review and test which was 1c133e3, 04af2bc, and 7f98345. We will look at the others soon.

Sp3EdeR commented 4 years ago

Hello, has there been any additional progress in this matter?

agserm commented 4 years ago

This is still in our queue, however it was put on a temporary hold. We are currently in Europe speaking at MeetingC++, code::dive, and several user groups about C++ and CopperSpice. These changes are in an area which requires a bit more intensive testing.

Sp3EdeR commented 4 years ago

I understand risk and testing and such. I even understand workload on an open source project. But so far as I can see, the whole project has absolutely no quality assurance other than the Copperspice documentation itself. So I believe that running two builds on unpatched and patched builds and then comparing the two might take an hour or two maximum. Maybe if there are further known clients, getting some documentation source to test with could take a few days.

This has gone on for months and I'm "beginning" to have the feeling that this project is not actually supported. My problem is that the fixes above are for blocking issues. I also do not desire to maintain my own fork of the project and develop the required CI system. So if the project is actually unsupported and exists only for Copperspice documentations please give your confirmation so that I would know that my best course of action is to move our documentation build system over to Doxygen instead.

bgeller commented 4 years ago

First of all, DoxyPress is used by more than just the CopperSpice project and as you know we do provide support for CopperSpice and DoxyPress. If you want extended support or priority service you should consider moving to our paid support, this option was officially added on our website. With paid support we can arrange to send you a pre-release copy of DoxyPress for your platform and include changes which are not ready for public release. This would solve your requirement that building a fork does not work for you.

Just so you know, we made a recent change to DoxyPress in December at the request of a Boost developer. They were not able to obtain support elsewhere and they are in the process of switching to DoxyPress. A few weeks ago we had another user explain that yes, the other project fixes some items but the over all internal design does not lend itself to maintainability. So like you he has a choice and he realized that moving to DoxyPress is the better option. So please be patient and gentle with your comments ( trust me I know this is very hard some days ), trust us that your suggestions might break things and we are reluctant to do that, and then be willing to simply ask us to reconsider and see if there is another way to fix your blocking concerns.

If you like to work with us we are more than willing and very excited. Our team ( yes there is a team ) is extremely committed to CopperSpice, DoxyPress, and our Youtube videos. I would like to encourage you to give us the benefit of the doubt and know that your issues are indeed important.

vdeurzen commented 4 years ago

Looks like you spent a fair bit of time debugging and digging into these issues, that's awesome! As a relatively new member of the team I can tell you that we take contributions very seriously. We are very strict about maintaining the stability of all our libraries. Therefore, we need to carefully test all contributed changes, which takes some time (we also need to maintain the CI infrastructure and ensure stable build environments for all our supported platforms).

I understand maintaining a fork is not an option and your issues are blocking. You have mentioned you have an issue with building DoxyPress, maybe we can advise you how get a stable build? That way you can solve your issues, and we can spend the necessary time for the review.

agserm commented 4 years ago

I'm a bit confused by your latest comment.

On October 14th you told us you were blocked and asked for help. The next day we posted a Windows binary for you to test. On October 16th you sent us an email thanking us and saying you would test our build. We gave you an update so I'm not sure how this issue is still blocking you.

As Tim suggested, maybe we can focus a bit on why you cannot build DoxyPress?

Sp3EdeR commented 4 years ago

I managed to build the project even before I asked for the build that you've provided to me with a selection of fixes/workarounds and outright "hacks" into the project files. I just thought I did something wrong with that build due to how the documentation came out as completely broken (mostly due to the markdown section bug). Since the build provided by you had the same issues, I did the rest of the fixes for the regression issues that came in since 1.2.10 which are part of this pull request.

I have looked at the code quite thoroughly for the above fixes, but unfortunately most of them came in with large scale commits that did not contain information about why the specific change was made that caused the regression issue. So without having the information of why the change was made or any test cases, I suppose I did the best.

The primary build issue is that the projects require a very specific set of dependencies which are not available as pre-built distributions so far as I can see. libclang prebuilt releases do not contain all dependencies and in most package managers a suitably old version is not available, the prebuilt packages distributed by your team do not work with the CMake toolchain (at least with the version I tested on) and there is no Visual Studio prebuilt. I did not want to put the work into sourcing all prerequisites and creating the build environment for all 3 platforms from source. That alone seems to me like a potentially multiday effort and I did not expect that breaking issues in Markdown processing, navigation tree synchronization and dot/uml support on Windows were to be left unaddressed for 2 months. I trust that the overhauled build system makes it far easier to get things started, but I do not have the time to check it.

vdeurzen commented 4 years ago

@Sp3EdeR Did the separately provided binary have the same issues or the official release? Because even if this PR would be merged and an official binary released, that may imply the issue is not fixed yet.

I understand the build process is not working for you. I can spend some time looking at it for Linux in the next few days to see if I can come up with a solution for finding or providing the dependencies.

Please understand that the number of libraries and the amount of code we are currently working on, makes prioritization complex and means some issues have to stay on our backlog a bit longer.

Sp3EdeR commented 4 years ago

@vdeurzen The forked version works alright for me at the moment, all of which is part of the pull request. I tested it on Windows, built with Visual Studio. The version sent to me by Barbara only had the fix for the "dot/uml" issue and that worked, but the rest were there. The official 1.3.5 version had the rest of these issues, but I have not tested 1.3.6 yet.

vdeurzen commented 4 years ago

@Sp3EdeR as I understand it then, your most urgent issue is solved?

Sp3EdeR commented 4 years ago

Info for 616c0b3ce031ac72a934c0387ae61ab4b035d2f2:

Observed:
- When Doxypress calls PlantUML for \startuml commands, it generates command line arguments, which contain: -graphvizdot "...dot.exedot" or -graphvizdot "...dotdot".
- PlantUML 1.2019.11 on Windows randomly (rarely) exited with an error that it cannot find "dot.exedot". Strangely most of the time (on most computers) it still works as expected when dot is in the system search path.
Changed:
- Doxypress now generates the correct -graphvizdot argument value as calculated by config.cpp.

Sp3EdeR commented 4 years ago

Info for ace54ee144189f23dd14e3afb4cb2d6f6dfbdf7a:

Observed:

When generating documentation with more than one \dot graph, Doxypress outputs errors into the warning file and all but one dot graph is not visible in the output. Changed:
The dot code stored file-name related information in static variables, which were only assigned to at the first function call. Subsequent calls used the originally generated file name. The affected static variables were changed into automatically scoped ones.

copperspice / doxypress

Bugfixes #28