Bugzilla – Full Text Bug Listing
| Summary: | xdc clean should 'just work' | ||
|---|---|---|---|
| Product: | [Technology] RTSC | Reporter: | Chris Ring <cring> |
| Component: | Core | Assignee: | Dave Russo <d-russo> |
| Status: | REOPENED --- | QA Contact: | |
| Severity: | major | ||
| Priority: | P3 | CC: | amitm, dfriedland |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | target:3.20.04 | ||
|
Description
Chris Ring
The problem is that the package in question was "corrupted" by manual removal of package.mak (which contains the list of files to remove). As a result, "xdc clean" does nothing in such a package. Since package.mak is removed as part of clean, if we generate package.mak to support package modified in the manner described, "xdc clean" will _always_ regenerate package.mak only to remove itself. Removal of just ./package is possible but this is not a real clean (since there are typically many other files that should be removed that are not in the ./package sub-directory). In fact, no user generated artifacts should be in the ./package sub-directory. (In reply to comment #1) > The problem is that the package in question was "corrupted" by manual removal > of package.mak (which contains the list of files to remove). As a result, "xdc > clean" does nothing in such a package. This 'corruption' happened as a result of running 'xdc release' and [apparently] failing to manually add the generated package.mak, with all my personal paths and settings, to the release. If 'keeping package.mak around' is the supported method of cleaning a package, maybe we should keep it around when "Pkg.attrs.exportSrc = true;"? Or maybe we need a new "Pkg.attrs.exportBld = true;" which Does The Right Thing and includes package.mak (or a lighter, clean-rule-only package.mak?), package.bld, and any other files necessary to build in the released package? > Since package.mak is removed as part of clean, if we generate package.mak to > support package modified in the manner described, "xdc clean" will _always_ > regenerate package.mak only to remove itself. I see this. And I also sympathize that, if the user's env isn't set up right (e.g. XDCPATH/config.bld), package.mak may even fail to be created. :( > Removal of just ./package is possible but this is not a real clean (since there > are typically many other files that should be removed that are not in the > ./package sub-directory). In fact, no user generated artifacts should be in > the ./package sub-directory. As no user content is in this directory, is there any harm in unconditionally removing ./package? I agree it may not be a true clean, but at least it cleans any metadata in ./package lying around from previous builds. IMHO, this is a fair compromise between the 'slow-but-correct-and-error-prone package.mak creation' and 'do nothing' that we have today. (In reply to comment #2) > > Since package.mak is removed as part of clean, if we generate package.mak to > > support package modified in the manner described, "xdc clean" will _always_ > > regenerate package.mak only to remove itself. > > I see this. And I also sympathize that, if the user's env isn't set up right > (e.g. XDCPATH/config.bld), package.mak may even fail to be created. :( > The problem seems to be that we want 1. a prebuilt released package without package.mak to be rebuildable "in-place" via: xdc clean; xdc and 2 "xdc clean" should not remake package.mak unnecessarily. Either we can provide an explicit mechanism for the released package to indicate that it is a "rebuildable in-place" package (e.g., a "rebuildable" attribute on a release) or rely on some implicit attribute of a released package that does not hold for the "development form" of a package (so clean does not trigger package.mak generation). There are some implicit differences that can be leveraged; e.g., .xdcenv.mak does not exist in released packages and will be created the first time you build in a released package, and package/package.rel.xml only exists in released packages. We could use the (non)existence of these files to know that package.mak should be regenerated during a "xdc clean". Using .xdcenv.mak means that "xdc clean" will only regenerate package.mak once. Using package/package.rel.xml means package.mak will be regenerated on every "xdc clean" of a _released_ package. Reliance on implicit attributes has the advantage that no changes need to be made to existing packages that require this clean behavior, but it feels very adhoc and it seems too likely to break in future updates. (In reply to comment #3) > (In reply to comment #2) > > Using .xdcenv.mak means that "xdc clean" will only regenerate package.mak once. > Using package/package.rel.xml means package.mak will be regenerated on every > "xdc clean" of a _released_ package. > Actually, using package.rel.xml might work: it's only when we detect that package.rel.xml exists that we regenerate package.mak, and this package.mak will automatically remove package.rel.xml as part of the clean. Since package.rel.mak will never be regenerated (in this location), subsequent cleans will be unaffected. "fixed" r1010 (xdc 3.21) also fixed in r1011 (xdc-v39, 3_20_01_45) Does not work in XDCtools 3.20.01.51. Comment from Chris Ring: [ I just tried to verify it with 3.20.01.51 GA, but cleaning a released package didn't seem to work (package/ dir and built bin/ dir is still around), so I'm wondering where the fix was implemented. ] The problem was fixed in cases where xdc is called at the base of a package but did not work if a multi-package clean is invoked.
fixed by removing an unnecessary recursion check in
3.21 (xdc-w07)
3.20 (xdc-v49)
Verified by cleaning an example codec (lib pkg w/dependent pkg) and server (executable pkg) from the CE 2.26.00.08 release using XDC 3.20.04.67_eng. The pre-existing package/ dir was correctly cleaned after generating the necessary package.mak's. Thanks! This change causes bundle cleans to break:
1. bundles require other package to build
2. if those package are cleaned prior to cleaning the bundle's make file
can't be recreated
3. since creation of the makefile is now required to clean a package, it's
impossible to reliably clean a bundle.
(In reply to comment #10) > This change causes bundle cleans to break: > 1. bundles require other package to build > 2. if those package are cleaned prior to cleaning the bundle's make file > can't be recreated > 3. since creation of the makefile is now required to clean a package, it's > impossible to reliably clean a bundle. Good find. However, I'd recommend we track this 'bundle clean' issue in a separate bug. AFAIK, cleaning bundles is not a very common use case, and the CCB can decide the priority of any further 'bundle clean' work. This particular bug, IMHO, should remain resolved/closed. |