New feature request (or bug ?) in HTML/CHM export : same unit name in two projects of a project group

[DeveloppeurPascal]

In my repositories I have some cases with a group of projects where each project has the same unit (like "fMain.pas" or "Unit1.pas" o:) for the main form). Of course I can generate a /docs file for each project in separate folders but it's more user friendly to have them all in the same HTML directory.

The problem is the web file name are the same because you ignore the folder where are stored the units. In the case the unit's HTML file available after a build is the good one for the last project, but all others go to it.

Separate identifiers (constant, methods, ...) pages are generated for each project but they are not available from the unit where they are declared or has the wrong value.

Here is a sample to see it in action :

SameUnitInTwoProjects.zip

We have a project group with a FMX and a VCL project. The two projects have a uSameUnitName.pas unit but they are stored in different folders.

In each unit I have two constants : CProject and CUnit3 or CUnit4.

In the generated HTML files we have the uSameUnitName.html of the second project with CMyUnit4 and CProject.
And for the CProject value, we have "Project2" from the second project.

Adding the relative folder path in each html file name could be a problem for users who don't have the problem, but perhaps you can detect you already have a file name when you generate them and add a number or hash as last part of its name if it's not the same unit than other projects ?

A good real sample is the repository https://github.com/DeveloppeurPascal/Gamolf-FMX-Game-Starter-Kit where projects has the same name for different units (like for "uConst.pas" or "uTxtAboutDescription.pas") or share units (like "_ScenesAncestor.pas" or "fMain.pas").

You can also try https://github.com/DeveloppeurPascal/FMX-Tools-Starter-Kit (the diproj file is in /src folder).

[zuobaoquan]

Thanks for your detailed explanation and the sample project!

Customization of directory layout is scheduled while designing new DocInsight manifest. For now, what about just qualify all elements by the project name if the generator find units with same name? (or just qualify the application/library projects but leave alone elements in packages as package don't allow same unit name typically.)

[DeveloppeurPascal]

adding the project name for units (and their content) with same name but different folder can be an easy fix for this problem
(or qualifying all units with the project where they are used)

in the future you have four cases to solve. using the relative (if we know how to define it) path (or a short signature of it) will be a better solution :

• units used by only one project (the most use case) => already work as expected
• units used by two of more projects (standard case when we use components or common libraries) => already work as expected
• units with same name but used by only one project => to solve (with path signature) or bypass (with project name as namespace)
• and units with same name used by one or more projects => to solve (with path signature) or bypass (with project name as namespace) but will generate duplicated pages in the build doc

not easy, I know, especially if I'm the first or only one to come forward with this type of case. ;)

[zuobaoquan]

Thanks! I've linked to this comment in the internal manifest design issue.

There are additional features that I want to support: API versions and platforms. I'll post some notes in the community forum then.