search

epics-modules / motor

APS BCDA synApps module: motor
https://epics-modules.github.io/motor/
20 stars 47 forks source link

consider splitting this module into a motorCore and individual driver repositories #55

Closed prjemian closed 5 years ago

prjemian commented 7 years ago

Tech-talk conversation today, Mark Rivers summarized:

"I have advocated splitting the motor module into a motorCore and individual repositories for each driver in the past, and I still think it is a good idea. With so many controllers in the current repository it is hard to make new releases. The last release of motor is 6-9, and it is now over 2 years old. There have been many bug fixes that are not in any official release."

This would be a major change so I have set a new milestone with major version number increment: R7-0. We can accumulate other changes for a R6-9 release while organizing our plans for separate motorCore and driver repositories.

kmpeters commented 7 years ago

I like this idea.

kmpeters commented 7 years ago

@MarkRivers, do you have suggestions for how we should split the motor support? If we follow the areaDetector model, we'll need to create a new project (epics-motor) to hold all the motor repositories that would be created.

I hope to start working on this after the next motor release.

MarkRivers commented 7 years ago

I don't see why we would necessarily need a new project, we could keep the new repositories in the existing epics-modules project if we want to. We could just split motor into motorCore, motorNewport, etc. That would be similar to the existing transient recorder repositories in epics-modules (transRecorder, TRCore, TRGeneralStandards, TRSIS). We could also make a new project, I don't have strong feelings on way or the other.

prjemian commented 6 years ago

In recent PDF slides, Kevin asked:

Q: Should SoftMotorSrc be included in the motor core repository? A: My opinion is no. It is another support module and serves as a template for other modules.

kmpeters commented 6 years ago

Takeaways from the recent satellite workshop on motion controls at the 2018 EPICS meeting at the APS:

@MarkRivers suggested an approach to creating the new motor driver repos:

  1. Create the driver modules in epics-motor
  2. Move the driver code to the new module
  3. Make the new module depend on motor in epics-modules
  4. Move motor from epics-modules to epics-motor when all the driver repositories have been created

epics-motor has been created. I will focus on creating the motor driver repositories after the 6-11 release of motor.

kmpeters commented 5 years ago

I asked @anjohnson for his thoughts on how the motor module could be split and he suggested using the EPICS base 7.0 modules as an example. The base 7.0 modules approach differs from the areaDetector approach in where the driver modules would reside when deployed inside the core motor module, but much of the outline of planned work would be the same.

I plan to begin the preparation for splitting the motor module next week. I will document the procedure that I believe works best for migrating drivers to individual repos after some testing. I'll post a message to tech-talk letting people know how they'll be impacted by the upcoming changes before I make any changes to the master branch.

MarkRivers commented 5 years ago

Can you explain how the areaDetector and EPICS base 7.0 models differ, i.e. what would the motor repository structure look like?

kmpeters commented 5 years ago

If the motor split followed the approach used by EPICS base 7.0 modules, the driver modules would reside in a "modules" subdirectory, rather than in the top-level directory. I haven't looked closely at the base-7.0 approach yet, but it looks like fewer files need to be edited to add a module to a deployed copy of motor.

The approach that is chosen needs to do the following:

  1. Allow building a single source tree on multiple platforms with different path conventions
  2. Minimize the amount of effort required to add a driver module to a deployed copy of motor
  3. Allow driver modules to be built outside of the motor module
kmpeters commented 5 years ago

@MarkRivers, did you use git filter-branch when you split areaDetector?

MarkRivers commented 5 years ago

When we split areaDetector we were not yet using git. The split and conversion from Subversion to git were done in a single step. I was a complete git novice at that point, and Michael Davidsaver did the work while I looked over his shoulder in awe.

mp49 commented 5 years ago

Hi,

I used filter-branch on some internal git modules a few years ago, and I documented the procedure. For example, this is how to extract an 'extensions' directory from a 'epics' git module, preserving the history:

cd /tmp/ git clone git+ssh://trac.sns.gov/var/repos/epics cd epics/ git remote rm origin git filter-branch --subdirectory-filter extensions -- --all git tag -d git tag | grep -E '.' mv * /home/controls/epics/extensions/master/ cd /home/controls/epics/extensions/master/ git add . git commit -m "Moving files from epics/support/" git remote add epics-branch /tmp/epics/ git pull epics-branch master git remote rm epics-branch cd /tmp/ rm -rf epics

The steps are:

kmpeters commented 5 years ago

@mp49, I've tried something similar. I'm cloning motor, removing the remote, and then cloning the local copy of motor to motorOms, and then attempting to filter-branch motorOms.

The problem I'm running into is that I can't use a simple call to git filter-branch like the one in your procedure:

git filter-branch --subdirectory-filter extensions -- --all

The driver modules I'm going to create will need files from many locations in the motor module:

motor/configure
motor/docs
motor/iocsh
motor/Makefile
motor/iocBoot/
motor/motorApp/Makefile
motor/motorApp/Db
motor/motorApp/Db/Makefile
motor/motorApp/<vendor>Src

I've done some googling, and it looks like I should be able to use filter-branch with an index-filter to remove all but a list of desired files:

git filter-branch --index-filter 'git rm --cached -qr --ignore-unmatch -- . && git reset -q $GIT_COMMIT -- $PATHS_TO_KEEP' --prune-empty -- "master"

where PATHS_to_KEEP is a space-separated list of files and dirs:

$ cat ../paths_to_keep.txt 
./configure
./iocBoot/iocWithAsyn/st.cmd.Vx
./Makefile
./motorApp/OmsSrc
$ PATHS_TO_KEEP=`cat ../paths_to_keep.txt`
$ echo $PATHS_TO_KEEP
./configure ./iocBoot/iocWithAsyn/st.cmd.Vx ./Makefile ./motorApp/OmsSrc

The above filter-branch command only operates on the index. If I do a git status after running the above filter-branch command, I see that something has changed:

$ git status
# On branch master
# Your branch and 'origin/master' have diverged,
# and have 2746 and 2772 different commits each, respectively.
#   (use "git pull" to merge the remote branch into yours)
#
nothing to commit, working directory clean

And I need to clone the filtered repo using a file:// path if I want to see the results of the filtering:

$ git clone file://motorOms motorOmsNew

When I look at the motorOmsNew, it looks mostly like motor; most of the files weren't deleted. This is consistent with the git status output showing that there are still thousands of commits. It isn't obvious to me why the filter-branch recipe I'm using doesn't produce the results that the blogs say it should.

kmpeters commented 5 years ago

The first answer on this stack overflow page describes the filter-branch approach I've attempted: https://stackoverflow.com/questions/2982055/detach-many-subdirectories-into-a-new-separate-git-repository

mp49 commented 5 years ago

Hi,

I'm not complete sure, but if filter-branch is told to keep some files that were involved in commits to do with many of the drivers (eg ./configure or ./Makefile) then the history of all those commits would be kept along with the history of the driver that is being separated out. Just guessing on that though.

If that is the case, maybe we don't need all the history on the 'auxiliary' files like IOC startup scripts or common Makefiles?

tboegi commented 5 years ago

You need to identify the files that should be "kept" from motor and go into Oms (for example). That can be done with a regular expression. To break out EthercatMC from axis it was OK to keep the .gitatttibutes, .gitignore files, and the everything Ether (in your case Oms) . So after the cloning into /tmp/motor, I used the following:

git filter-branch --prune-empty --index-filter ' git ls-files -z | egrep -zv "(Ether|gitattributes|gitignore)" | xargs -0 -r git rm --cached -q ' HEAD

kmpeters commented 5 years ago

If that is the case, maybe we don't need all the history on the 'auxiliary' files like IOC startup scripts or common Makefiles?

@mp49, I think that is a reasonable approach if other attempts at preserving the history of the auxiliary files are unsuccessful.

I've created a much simpler git repo to test different git filter-branch approaches (https://github.com/kmpeters/testIoc). I'm abandoning the approach from the stack overflow page; it doesn't work as advertised. It leaves my testIoc history unchanged in all of my tests.

I'm going to try @tboegi's approach next.

kmpeters commented 5 years ago

I figured out why the stack-overflow approach didn't work for me. The paths to the files to be kept were incorrect:

$ cat ../paths_to_keep.txt 
./configure
./iocBoot/iocWithAsyn/st.cmd.Vx
./Makefile
./motorApp/OmsSrc

If I remove the ./ from the start of each path, the approach works as advertised:

$ cat ../paths_to_keep_better.txt 
configure
iocBoot/iocWithAsyn/st.cmd.Vx
Makefile
motorApp/OmsSrc

$ PATHS_TO_KEEP=`cat ../paths_to_keep_better.txt`

$ git filter-branch --index-filter 'git rm --cached -qr --ignore-unmatch -- . && git reset -q $GIT_COMMIT -- $PATHS_TO_KEEP' --prune-empty -- master
Rewrite ab6092f8b5dc3f07a055d4039bac44dd2c88bda4 (2491/2776)error: duplicate parent 1d6f076c133fe4d24f534ef3eb6a9f921f88dace ignored
Rewrite 724dd71a723a4fb36fd84a08b4665091002cffd9 (2503/2776)error: duplicate parent 5f6bedb68cd6573eeb663061eccfa8c2c4cbcd56 ignored
Rewrite ae84076e42347a365b360d1d5f1583a07805b02d (2505/2776)error: duplicate parent 12d39bb3775470652db46ac84ad2ee951466a4f3 ignored
Rewrite c844aae51507d8e1c421c15f12d221043fed654f (2509/2776)error: duplicate parent a84ef3005f2c0da4389106f3f53fc63cf2b89bad ignored
Rewrite 6cb7ff2a5e4d19aad382f81b2c5fe50eec1e7da8 (2533/2776)error: duplicate parent 5d286f01e339bd2d51af4907d6c6cf36cc92e3ea ignored
Rewrite 14b1070b7d64fb95e7dcf4be06b9386a088cf258 (2543/2776)error: duplicate parent a9121a2824e3ac44036177e1f1382de75aff0a75 ignored
Rewrite 6b9ca72120ce26c074a04f833363bb4c7400bb8d (2545/2776)error: duplicate parent 5a01a85096f05a6134b759eba24e071e8e40f491 ignored
Rewrite 345fecadb8c1a20448ee54be3b9f2865da5fa0e5 (2555/2776)error: duplicate parent 6e24a0ef616f65085ec366f84b258152b84c09c8 ignored
Rewrite 8966aeabf292874de8c78754e95e14cde1f1c776 (2568/2776)error: duplicate parent 18b64e0e30e718f1ac32fd3f173e8a2bda93c9d9 ignored
Rewrite 0bc027e2e42102554c0c9a7360dc30afda9a6a63 (2584/2776)error: duplicate parent fbac9ccdaad366f79249eff597b775b59cb0a67f ignored
Rewrite 4ade0a7f3717696d20dcfc75895acf4489c1fa40 (2588/2776)error: duplicate parent 27848d5e4a5a275484b2424ce50e0e52bcb608c7 ignored
Rewrite 5245991323fb8c73cd6383e064da7b02c2629fea (2603/2776)error: duplicate parent 27746c9d4ecac84de0102b0d69f5bbe36d2ac846 ignored
Rewrite 6990911206d54e5bf0ec1e4ba7284154b45866cf (2679/2776)error: duplicate parent 0df0d254155c4a668437e5c5e471c99e2734d2f9 ignored
Rewrite 09fcb5986c7bcb0d88d75949cf3ec40d680f4c17 (2725/2776)error: duplicate parent c888113179d9ced02223babd8dc91c74f9c30137 ignored
Rewrite 548a013a38ea4c2b44953463162aaeb240a3efed (2729/2776)error: duplicate parent 7802ab6eb7277fbf89c5e005d6efaf1f51fc85ce ignored
Rewrite 000082b55a199c811b4570d2001da6822b6527ba (2734/2776)error: duplicate parent c96421202cfca22461f51f1b4efdfbe67e169102 ignored
Rewrite c09b49c245aa0b8ad3f0cbb38e434de045f22d9d (2736/2776)error: duplicate parent f020578cfd299880fbd91eeab766f2febfce0f40 ignored
Rewrite 741d4292cd78cf7c059426ecf0aea6269c4f9a50 (2740/2776)error: duplicate parent 49d07ef1a710b8a8bae73e6be5693fdfeaee22d1 ignored
Rewrite f6e9f2620981aecd4e4793d56bbdf858dcb28a21 (2743/2776)error: duplicate parent 29c751eb2e47d90e87e2275b7ab2bf7403a27e2f ignored
Rewrite c6e655d8b3459a265af4b78853173d1f81439803 (2751/2776)error: duplicate parent 1890e72bb8ce41eed60c70adef2fff8474ee8671 ignored
Rewrite d7bc85109d708177643d81d8129ef734b7ced851 (2776/2776)
Ref 'refs/heads/master' was rewritten

$ find . | grep -v git
.
./Makefile
./configure
./configure/CONFIG
./configure/CONFIG_SITE
./configure/Makefile
./configure/RELEASE
./configure/RULES
./configure/RULES.ioc
./configure/RULES_DIRS
./configure/RULES_TOP
./iocBoot
./iocBoot/iocWithAsyn
./iocBoot/iocWithAsyn/st.cmd.Vx
./motorApp
./motorApp/OmsSrc
./motorApp/OmsSrc/MAX_trajectoryScan.h
./motorApp/OmsSrc/MAX_trajectoryScan.st
./motorApp/OmsSrc/Makefile
./motorApp/OmsSrc/README
./motorApp/OmsSrc/devMAXv.cc
./motorApp/OmsSrc/devOms.cc
./motorApp/OmsSrc/devOms.dbd
./motorApp/OmsSrc/devOms58.cc
./motorApp/OmsSrc/devOmsCom.cc
./motorApp/OmsSrc/devOmsCom.h
./motorApp/OmsSrc/devOmsPC68.cc
./motorApp/OmsSrc/drvMAXv.cc
./motorApp/OmsSrc/drvMAXv.h
./motorApp/OmsSrc/drvOms.cc
./motorApp/OmsSrc/drvOms.h
./motorApp/OmsSrc/drvOms58.cc
./motorApp/OmsSrc/drvOms58.h
./motorApp/OmsSrc/drvOmsCom.h
./motorApp/OmsSrc/drvOmsPC68.cc
./motorApp/OmsSrc/drvOmsPC68Com.h
$

The commits referenced in the duplicate-parent warnings are all merges of pull requests. They are included in the resulting repo, even if they don't reference any of the files in $PATHS_TO_KEEP.

kmpeters commented 5 years ago

It seems obvious to me that the history for files in motorApp's Src & Db dirs should be retained, as well as vendor-specific examples from motor/iocBoot/iocWithAsyn.

It is not obvious to me if the history of the 'auxiliary' files like Makefiles and common examples like motor/iocBoot/iocWithAsyn/st.cmd.Vx are valuable. Including the history of these auxiliary files results in the inclusion of many changes for other vendors.

I welcome suggestions for how to proceed.

MarkRivers commented 5 years ago

I don't think you need to preserve the history of Makefiles or st.cmd.Vx. The Makefiles will need to change anyways, and the st.cmd.* files tend to be controller-specific and will be renamed and changed as well once they are in the controller-specific repository.

kmpeters commented 5 years ago

I don't think you need to preserve the history of Makefiles or st.cmd.Vx. The Makefiles will need to change anyways, and the st.cmd.* files tend to be controller-specific and will be renamed and changed as well once they are in the controller-specific repository.

Ok.

I found a way to remove the empty pull-request merge messages that weren't removed by the original filter-branch call:

git filter-branch --prune-empty --parent-filter 'sed "s/-p //g" | xargs -r git show-branch --independent | sed "s/\</-p /g"'

Source: https://stackoverflow.com/questions/9803294/prune-empty-merge-commits-from-history-in-git-repository

kmpeters commented 5 years ago

Here is my first attempt at splitting a driver directory from the motor module: https://github.com/kmpeters/motorOms

motorOms/omsApp/src retains the driver development history. The application and IOC were generated by makeBaseApp.pl from base-3.15.6. The areaDetector approach is used to include the IOC.

I've only built motorOms outside of the motor tree, using the EXAMPLE_*.local files in the configure dir.

The next step is to test building motorOms inside the motor tree.

mp49 commented 5 years ago

I tested cloning it, and it built fine (I just had to create a configure/RELEASE.local).

The history looks good too (all 18 years of it!)

kmpeters commented 5 years ago

Can you explain how the areaDetector and EPICS base 7.0 models differ, i.e. what would the motor repository structure look like?

@MarkRivers, I've been doing some testing of building motorOms inside motor (https://github.com/kmpeters/motor/tree/motor-split-testing) and I now have a better answer to this question.

In areaDetector all of the submodules are standalone modules that install their build products to the top-level of the submodule. IOCs that want to use areaDetector need many areaDetector variables defined in their RELEASE file: AREA_DETECTOR, ADCORE, ADSUPPORT, and the AD. If the areaDetector approach is used for the motor split, an IOC would need lots of new MOTOR* variables defined in their RELEASE file.

The build products of EPICS base 7.0 modules are installed to the top-level base directory if they are built inside the base/modules directory. If the EPICS base 7.0 approach is used for the motor split, an IOC would still only need MOTOR defined (for all the drivers that were built inside the motor module), because all of the build products would get installed where they currently do. Drivers that are built outside the motor tree would require an additional line in the IOC's RELEASE file.

MarkRivers commented 5 years ago

I understand, thanks.

tboegi commented 5 years ago

Can we comment out EPICS_BASE from configure/RELEASE as well ? # EPICS_BASE should appear last so earlier modules can override stuff: EPICS_BASE = /APSshare/epics/base-3.15.6

And in the same commit, add *.local to the .gitignore file

kmpeters commented 5 years ago

Can we comment out EPICS_BASE from configure/RELEASE as well ? # EPICS_BASE should appear last so earlier modules can override stuff: EPICS_BASE = /APSshare/epics/base-3.15.6

I'm going to remove EPICS_BASE from motorOms's RELEASE file, rather than comment it out.

And in the same commit, add *.local to the .gitignore file

Yes.

kmpeters commented 5 years ago

Question for everyone:

Is there value in having a top-level motorVendor/iocBoot/iocVendor directory with cmd/substitution examples or is it sufficient to have usable examples in motorVendor/iocs/vendorIOC/iocBoot/iocvendor?

I don't like the idea of having two copies of examples, but I also think that only including them in the iocvendor dir makes them much harder to find.

anjohnson commented 5 years ago

@kmpeters asked:

Is there value in having a top-level motorVendor/iocBoot/iocVendor directory with cmd/substitution examples or is it sufficient to have usable examples in motorVendor/iocs/vendorIOC/iocBoot/iocvendor?

This sounds like a situation where building a modules/motor<Vendor> sub-application should install its example(s), so the install tree (usually the top-level motor application) then collects a copy of the examples from all the vendor trees that have been built underneath it.

One way to do that might be to make them makeBaseApp templates, although that may have a few rough edges in it so please work with me directly if you want to go this way (we don't currently have a makeBaseApp template for making new makeBaseApp templates!). Users will have to instantiate a specific template by running makeBaseApp.pl in a new top-level directory before they can run them though, so they won't be quite as easy to use as your existing examples might be but in the long run I suspect they'll be more convenient. I've recently started developing a similar set of makeBaseApp templates for my APS-U work.

BTW (aside): The synApps <top>/iocsh directories should probably be install targets instead of stored directly in git, so the scripts get copied to the right place if a user points INSTALL_LOCATION to an external directory. There is a facility in the build system intended for exactly this kind of file copying, look at the comments at the top of <base>/configure/CONFIG_FILE_TYPE for details.

kmpeters commented 5 years ago

@anjohnson, when I mention "examples" in the context of new motor modules, I'm usually referring to example IOC motor configuration, which isn't easily installed to the top-level motor directory, not the IOC binary, which could be easily installed to the top-level motor directory. This is one such example:

https://github.com/epics-modules/motor/blob/master/iocBoot/iocNoAsyn/st.cmd.Vx

st.cmd.Vx is useful if you want to see the configuration options for a MAXv controller, but the lack of an associated substitutions file makes it extremely unlikely that anyone is actually using st.cmd.Vx as a starting point for an IOC with MAXv support.

I don't think creating a new makeBaseApp template would be very helpful. I'm already using makeBaseApp to generate most of the example IOC that is included in the new driver modules. The vast majority of the changes I make to the example IOC will be controller & vendor specific. Here is how I've handled the example OMS motor configuration:

https://github.com/kmpeters/motorOms/tree/master/iocs/omsIOC/iocBoot/iocoms

BTW (aside): The synApps /iocsh directories should probably be install targets instead of stored directly in git, so the scripts get copied to the right place if a user points INSTALL_LOCATION to an external directory. There is a facility in the build system intended for exactly this kind of file copying, look at the comments at the top of /configure/CONFIG_FILE_TYPE for details.

I agree that the contents of iocsh should probably be install targets. @keenanlang has created most of them. We should probably have an offline discussion about those files, since they are not unique to motor.

kmpeters commented 5 years ago

git filter-branch --prune-empty --index-filter ' git ls-files -z | egrep -zv "(Ether|gitattributes|gitignore)" | xargs -0 -r git rm --cached -q ' HEAD

@tboegi, thanks for this filter-branch recipe. The stack-overflow approach that worked for the OMS support failed for the Newport support. Your approach worked on the first attempt. It is very convenient to be able to run git ls-files | egrep "<pattern>" to see which files will be retained.

kmpeters commented 5 years ago

I've started the conversion of the Newport support to its own module: https://github.com/kmpeters/motorNewport

I've also documented the general approach I plan to use when I begin the actual split: https://github.com/epics-modules/motor/wiki/Splitting-the-motor-module

I plan to document the steps required to create the motorNewport repo next week. After that I'll send a message to tech-talk announcing the beginning of the split and then begin removing drivers from motor's master branch.

I plan to redo the creation of motorOms so that the iocoms directory is instead named iocOms. If there are no objects to the final version of motorNewport, I shouldn't need to recreate that module.

kmpeters commented 5 years ago

I'm not finished with motorNewport yet. I need to find a way to install .template and .req files into the IOC's top-level db directory, which currently doesn't work. This would eliminate the need to modify the IOC's Db/Makefile when motorNewport is built outside of motor.

I've discovered a bigger problem with the epics base 7.0 approach to submodules: motor drivers built inside the motor/modules will overwrite files in motor/configure if their config files have newer timestamps.

MarkRivers commented 5 years ago

Be careful. Currently if you run “make uninstall “ in a base submodule it deletes the base/configure directory!

kmpeters commented 5 years ago

Andrew suggested making this change to protect against the removal of the configure directory:

https://github.com/kmpeters/motor/commit/57f3a9b566fb8811dadcf004120b7978f452a126

The situation that scares me more is if motor doesn't define INSTALL_CONFIG and modules/motorVendor leaves it empty (INSTALL_CONFIG =), doing a make distclean in modules/motorVendor tries to remove /bin from your system.

Here is an example from my testing with motorNewport:

[hobbes ~/epics/motor-split/build-testing/motor] grep -r INSTALL_CONFIG . | grep -v git
./configure/RULES_TOP:#!  INSTALL_CONFIG =
./modules/motorNewport/configure/RULES_TOP:INSTALL_CONFIG =

[hobbes ~/epics/motor-split/build-testing/motor] cd modules/motorNewport

[hobbes ~/epics/motor-split/build-testing/motor/modules/motorNewport] make distclean
make -C ./configure realclean 
make[1]: Entering directory `/home/kmpeters/epics/motor-split/build-testing/motor/modules/motorNewport/configure'
rm -rf O.*
make[1]: Leaving directory `/home/kmpeters/epics/motor-split/build-testing/motor/modules/motorNewport/configure'
make -C ./newportApp realclean 
make[1]: Entering directory `/home/kmpeters/epics/motor-split/build-testing/motor/modules/motorNewport/newportApp'
make -C ./src realclean 
make[2]: Entering directory `/home/kmpeters/epics/motor-split/build-testing/motor/modules/motorNewport/newportApp/src'
rm -rf O.*
make[2]: Leaving directory `/home/kmpeters/epics/motor-split/build-testing/motor/modules/motorNewport/newportApp/src'
make -C ./Db realclean 
make[2]: Entering directory `/home/kmpeters/epics/motor-split/build-testing/motor/modules/motorNewport/newportApp/Db'
rm -rf O.*
make[2]: Leaving directory `/home/kmpeters/epics/motor-split/build-testing/motor/modules/motorNewport/newportApp/Db'
make[1]: Leaving directory `/home/kmpeters/epics/motor-split/build-testing/motor/modules/motorNewport/newportApp'
perl /APSshare/epics/extensions-base/3.14.12.3-ext1/bin/linux-x86_64/cvsclean.pl
rm -rf /dbd /include /doc /html /javalib /templates /db /adl /alh /cfg /edl /lib/perl
rm -rf /bin
rm: cannot remove \u2018/bin\u2019: Permission denied
make: *** [realuninstall] Error 1

I was very thankful I don't have write access to /bin

kmpeters commented 5 years ago

Be careful. Currently if you run “make uninstall “ in a base submodule it deletes the base/configure directory!

@anjohnson made a number of very helpful suggestions that I applied to the motor-split-testing branch and driver modules today that make it much safer to type "make uninstall" everywhere.

kmpeters commented 5 years ago

Now that I'm nearing the end of the splitting of the motor module, I notice that both the ACR controllers: https://github.com/epics-motor/motorACR and PC6K controllers: https://github.com/epics-motor/motorPC are made by Parker: http://www.parkermotion.com/products/Controllers____30_32_80_567_29.html

Should these two modules be combined into a single motorParker module? I failed to notice that the ACR controllers were made by Parker and that Parker isn't using the Compumotor name anymore.

I'm comfortable having multiple driver modules associated with a single vendor, especially when they have different authors. In this case, however, it seems like combining the two might be beneficial. The addition of an EPICS driver for a new Parker controller is likely to result in the creation of a third driver module in the absence of a clearly-named Parker module.

MarkRivers commented 5 years ago

Combining them into a Parker module is fine with me.

kmpeters commented 5 years ago

Ok. I'll combine them.

kmpeters commented 5 years ago

motor R7-0 has been released. I'll email tech-talk later today. Thanks to everyone for your feedback during this process.