'make distclean' inside a submodule

Bug #1722535 reported by Andrew Johnson
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
EPICS Base
Fix Released
Low
Andrew Johnson

Bug Description

Running 'make distclean' inside a base-7.0 submodule deletes the parent module's bin and lib directories. Not a major problem, but a little unfriendly and unexpected:

woz$ git st
On branch libcom/master
Your branch is up-to-date with 'origin/libcom/master'.
nothing to commit, working directory clean
woz$ make distclean
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C ./configure realclean
rm -rf O.*
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C ./src realclean
rm -rf O.*
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C ./RTEMS realclean
rm -rf O.*
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C ./test realclean
rm -rf O.*
perl -CSD /Users/anj/Software/epics/base-7.0/bin/darwin-x86/cvsclean.pl
rm -rf ./../../dbd ./../../include ./../../doc ./../../html ./../../templates ./../../db ./../../adl ./../../alh ./../../cfg ./../../edl ./../../lib/perl ./../../lib/pkgconfig ./../../configure
rm -rf ./../../bin
rm -rf ./../../lib

Revision history for this message
Ralph Lange (ralph-lange) wrote :

Yes, I know.
It's on my list of things to fix - somewhere in the middle.

Revision history for this message
Andrew Johnson (anj) wrote :

More importantly I just noticed that it also removed my $(TOP)/configure directories, which IIRC you had already discovered and reported.

Changed in epics-base:
status: New → Confirmed
Revision history for this message
mdavidsaver (mdavidsaver) wrote :

I believe this was fixed at some point prior to 7.0.1 .

Changed in epics-base:
status: Confirmed → Fix Released
Revision history for this message
mdavidsaver (mdavidsaver) wrote :

Ha, I need to qualify this (really I just didn't read "inside submodule'). I no longer see this issue because it has been superseded by another.

$ cd modules/libcom
$ make distclean
configure/CONFIG:6: EPICS_HOST_ARCH is not set.
configure/CONFIG:22: Build error: EPICS_BASE not set after including RELEASE files.
configure/CONFIG:26: *** Makefiles loaded: Makefile configure/CONFIG configure/RELEASE. Stop.
$ ls ../RELEASE*
../RELEASE.linux-x86_64.local

I'm guessing that there is a chicken+egg issue here with need to have EPICS_BASE in order to find EPICS_HOST_ARCH, but needing EPICS_HOST_ARCH in order to find EPICS_BASE.

Changed in epics-base:
status: Fix Released → Confirmed
Revision history for this message
Andrew Johnson (anj) wrote :

What should 'make realuninstall' do to the install directories (bin, lib, dbd, cfg, include etc.) when run in a sub-module? Deleting just the files that this sub-module installs is not an option (without a *lot* more work tracking installed files so they can later be uninstalled). The distclean target depends on realuninstall so that's why I'm asking about realuninstall.

Currently we always delete most install directories, but only delete the configure directory when INSTALL_LOCATION is not TOP. That prevents us from deleting our own configure directory, but it doesn't help with sub-modules of base-7.0, hence this bug.

My current thought is to de-fang the realuninstall rule in a sub-module's TOP when INSTALL_LOCATION is EPICS_BASE, and never add the configure directory to the list of directories that get uninstalled. You can still uninstall Base-7.0 but only from the real top. Should we do the same for the uninstall target?

Revision history for this message
Andrew Johnson (anj) wrote :

This was fixed with e92a9ae and included in the 7.0.2.2 release

Changed in epics-base:
status: Confirmed → Fix Committed
assignee: nobody → Andrew Johnson (anj)
status: Fix Committed → Fix Released
Revision history for this message
Andrew Johnson (anj) wrote : Re: [Bug 1722535] Re: 'make distclean' inside a submodule

Hi Mark,

On 5/13/19 5:57 PM, Mark Rivers wrote:

Running 'make distclean' inside a base-7.0 submodule deletes the parent module's bin and lib directories. Not a major problem, but a little unfriendly and unexpected:

It also deleted the parent module's configure directory, right? I think that was a more serious problem, since there can be local edits there to add new ARCHs, etc.

True, although I might not have known that when I wrote the original description for this bug report. Anyway that's all fixed in 7.0.2.2 which completely disables the dangerous targets from RULES_TOP when building a sub-module:

tux% cd modules/database/
tux% make uninstall
/local/anj/base-7.0/configure/RULES_TOP:66: *** Target 'uninstall' not available in a submodule. Stop.
tux% make help
Usage: gnumake [options] [target] ...
Targets supported by all Makefiles:
     all - Same as install (default rule)
     inc - Installs header files
     build - Builds and installs all targets
     install - Builds and installs all targets
     buildInstall - Same as install (deprecated)
     clean - Removes the O.<arch> dirs created by running make
                      In O.<arch> dir, clean removes build created files
     realclean - Removes ALL O.<arch> dirs
                      Cannot be used within an O.<arch> dir
     rebuild - Same as clean install
     archclean - Removes O.<arch> dirs but not O.Common dir
     depclean - Removes .d files from all O.<arch> dirs.
     cvsclean - Removes backup files etc. from all dirs below
     runtests - Run self-tests, summarize results immediately
     tapfiles - Run self-tests, save to O.<arch>/*.tap files
     test-results - Summarize all O.<arch>/*.tap files
     clean-tests - Removes all O.<arch>/*.tap files
"Partial" build targets supported by Makefiles:
     host - Builds and installs linux-x86_64 only.
     inc.<arch> - Installs <arch> only header files.
     build.<arch> - Builds and installs <arch> only.
     install.<arch> - Builds and installs <arch> only.
     clean.<arch> - Cleans <arch> binaries in O.<arch> dirs only.
Targets supported by top level Makefile:
     help - Prints this list of valid make targets
Object targets are supported by the O.<arch> level Makefile .e.g
     xxxRecord.o

- Andrew

--
Complexity comes for free, Simplicity you have to work for.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.