Paths for debian

[tboegi]

No description provided.

[anjohnson]

Hi Torsten,

Are you using an extensions tree on a shared disk that has builds for all of those Debian-based distro's at the same time? If not you should be able to configure each extensions tree separately — CONFIG_SITE files are supposed to be edited locally as needed for the specific installation and I'm generally reluctant to add special cases to distributed files that are meant to be edited locally anyway.

I have some unmerged changes to this tree which I started doing in 2015 but haven't even published yet which cleans up some of the files and removes old stuff including unsupported targets. We also have another copy of the extensions configure tree which is provided as a template inside Base — running makeBaseExt.pl -t simple simple is supposed to instantiate an extensions build area and create you an extension called simple, although the latter part doesn't work with any Base branch at the moment and the script gives me an error, but it does create the extensions tree in the current directory. I was originally planning that this repository would disappear and be replaced by that template mechanism so we would only have to maintain the template files in Base, but I got side-tracked while working on that. I just looked at the differences between the two and there are quite a lot of them although they do seem to be mostly cosmetic.

BTW a machine running Raspbian should have EPICS_HOST_ARCH=linux-arm or similar so it would never actually run the epicsfinddist.sh file which is only referenced from your CONFIG_SITE.linux-x86_64.linux-x86_64 changes. Even if you were cross-building for linux-arm from an Intel host that particular CONFIG_SITE file is only used for when building for both the Intel host and target. As a general point we don't put scripts in $(TOP) so if I accepted this the script would have to move, but to be honest I would need persuading for this to go into the extensions tree.

Your RELEASE and CONFIG_SITE changes match what we've been doing elsewhere so I'd good with merging them, and I don't think they'll conflict with the other change I've talked about.

So what should you do with this now? I'd be happy to merge your first two commits as is, but not the last two without more work. I don't want to ask you to do work that may never be used, but other than merging PR's I'm not in a position to work on the extensions tree myself right now.

If you wanted to take a look at the changes I made so far you can find them on the cleanup branch at https://github.com/anjohnson/extensions.git — the only uncommitted changes I have here added some edits to the src/Makefile. That doesn't include the additional modifications that have also been made to the makeBaseExt template in Base which should also be applied, and we need to fix the makeBaseExt.pl script in Base as well...

• Andrew

[tboegi]

Hej Andrew,
thanks for the long comment.
The short answers:

• Yes, I use the same tree for Raspbian and Debian, the next test would be Centos.
  Having .local files will ease the co-existance of at least arm and x86.
• I will open a new PR with the 2 first patches allowing local files.
  (Squash them into 1 commit, update .gitignore, fix typos)
• If it helps, I can have a look into your "cleanup" branch, and turn that into a PR.
  Please say just yes or no.
  (And now the part where I don't want to make too many promises:)
• I will look into makeBaseExt.pl with (help of my rusty perl knowledge.)
• I think I will try to convert epicsfinddist.sh into a "configure" script.
  (What do you think about a "configure" script as other open source projects have it?)