Global profile ?

As far as I know profiles are defined per workspace.
Is it possible to define global profiles ?

Expected Behavior

Such profiles could be stored in ~/.config/catkin/profiles/ the same manner as in the workspaces.

Given a --profile is-my-best-profile the expected behavior would first look-up the ~/.config/catkin/profiles/ folder for an existing profile, then look locally - in the current workspace - if the profile exists and fallback to the current behavior. I guess the local definition should override the global one.

A extra keyword would then differentiate between setting up a local definition and a global one :

catkin config --global --profile debug -x _debug --cmake-args -DCMAKE_BUILD_TYPE=Debug

Actual Behavior

???

Side note

• So far I only could come up with aliases to ease setting up the profiles given in the cheat sheet :

profile-debug: config --profile debug -x _debug --cmake-args -DCMAKE_BUILD_TYPE=Debug
profile-release: config --profile release -x _release --cmake-args -DCMAKE_BUILD_TYPE=Release

• The --global keyword comes straight from git, a config scheme similar to these of git would boost the adoption of the new feature.

[mikepurvis]

I’m becoming very interested in this feature. We’d like to be able to ship our developers a profile in /etc somewhere with flags that match our CI build.

So I think I’m looking for a couple things:

• Additional search paths for named profiles— if not found in the workspace, look in a user location like ~/.config/catkin, and then look in /etc/catkin_tools, then finally fall back to a default shipped with catkin_tools itself.
• The ability to save a default profile which seeds newly created workspaces. It’s not clear to me whether this default should be copied into each workspace on first init/config/build, or simply accessed as a fallback behaviour on every individual use.

With some guidance in these areas, it’s likely we can get together a PR.

@tspicer01 @servos @efernandez

[artivis]

@efernandez No unfortunately I didn’t have time so far to play with this. The quick workaround was to define catkin aliases

profile-debug: config --profile debug -x _debug --cmake-args -DCMAKE_BUILD_TYPE=Debug
profile-release: config --profile release -x _release --cmake-args -DCMAKE_BUILD_TYPE=Release
# etc ...

in ~/.config/catkin/verb_aliases/my_aliases.yaml since catkin already looks in ~/.config/catkin/verb_aliases/ for aliases. Then invoke with:

~/workspace$ catkin profile-release
~/workspace$ catkin build --profile release

@mikepurvis I do not know how complicated/beneficial it would be to look in /etc/catkin_tools, wouldn’t it be simpler to somehow set soft-links from your install path to ~/.config/catkin ?
I’m simply afraid that adding an extra layer of path to check would just make things obscure to the end user (workspace-local profiles in ~/workspace/.catkin_tools/profiles, some more in ~/.config/catkin and finally /etc/catkin ?? Where the h** is my profile definition xD).

From catkin_tools doc : Verb alias files in the verb_aliases directory are processed in alphabetical order, so files which start with larger numbers will override files with smaller numbers. I imagine the same system could be adopted for profiles. Given a --global argument to catkin config --profile, it writes the appropriate file(s) to ~/.config/catkin rather than in the workspace wouldn’t be too complicated. First difficulty, profiles seems to have a folder-based scheme rather than file-based (see ~/workspace/.catkin_tools/profiles after defining a couple profiles).
Regarding your second point @mikepurvis, on first build of a fresh ws, a default profile folder is copied in the workspace’s .catkin_tools. Thus if the custom-default is not copied locally, depending on the fallback rule there might be conflicts and most certainly confusion. It should somehow be very explicit that the default profile as been overloaded.