You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Deferred from #11 (which now renames a program/library/package's
.dpr/.dpk, .dproj, and .res when the module name changes). Updating .groupproj files was split out because it needs its own file handler
and carries higher risk.
Background
.groupproj is NOT in the default filespec (*.pas;*.dpr;*.dpk;*.dproj)
and, unlike .dproj, has no dedicated handler -- if scanned it would be
mis-tokenized as Pascal. When #11 renames a project's .dproj, any .groupproj that references the old .dproj filename becomes stale.
A .groupproj references a renamed project in three places:
<Projects Include="path\Old.dproj">
<MSBuild Projects="path\Old.dproj"/> (inside the generated targets)
MSBuild target names derived from the project name by replacing
non-alphanumeric characters with _ (e.g. Delphi_Lexer_TokenDump,
plus :Clean / :Make variants and the CallTarget list).
Target-name rewriting (the dot/dash -> underscore munging) is the
fragile part and can corrupt the group if imperfect. Decide whether to
do path references only, or full target-name rewriting, when picking
this up. Path references (Projects Include / MSBuild Projects) are the
build-critical ones; target names are cosmetic labels for a normal
group build.
Fix approach
Add a dedicated raw-text .groupproj handler (mirroring ProcessDprojFile: operate on the source string to preserve line
endings / BOM). When a project file is renamed via the #11 path, rewrite
matching .dproj path references (and, if in scope, the derived target
names) in every scanned .groupproj.
Acceptance criteria
.groupprojProjects Include and MSBuild Projects paths updated when a project is renamed
Target names updated, or explicitly documented as out of scope
Opt-in via *.groupproj in the filespec; line endings / BOM preserved
Deferred from #11 (which now renames a program/library/package's
.dpr/.dpk, .dproj, and .res when the module name changes). Updating
.groupprojfiles was split out because it needs its own file handlerand carries higher risk.
Background
.groupprojis NOT in the default filespec (*.pas;*.dpr;*.dpk;*.dproj)and, unlike
.dproj, has no dedicated handler -- if scanned it would bemis-tokenized as Pascal. When #11 renames a project's
.dproj, any.groupprojthat references the old.dprojfilename becomes stale.A
.groupprojreferences a renamed project in three places:<Projects Include="path\Old.dproj"><MSBuild Projects="path\Old.dproj"/>(inside the generated targets)non-alphanumeric characters with
_(e.g.Delphi_Lexer_TokenDump,plus
:Clean/:Makevariants and theCallTargetlist).Scope decisions carried over from #11
.groupprojwhen*.groupprojis inthe effective
--filespec(consistent with the .res opt-in in Renaming a program/library/package name should also rename its .dpr/.dproj/.res files #11).fragile part and can corrupt the group if imperfect. Decide whether to
do path references only, or full target-name rewriting, when picking
this up. Path references (Projects Include / MSBuild Projects) are the
build-critical ones; target names are cosmetic labels for a normal
group build.
Fix approach
Add a dedicated raw-text
.groupprojhandler (mirroringProcessDprojFile: operate on the source string to preserve lineendings / BOM). When a project file is renamed via the #11 path, rewrite
matching
.dprojpath references (and, if in scope, the derived targetnames) in every scanned
.groupproj.Acceptance criteria
.groupprojProjects IncludeandMSBuild Projectspaths updated when a project is renamed*.groupprojin the filespec; line endings / BOM preserved.groupprojreference update