Prefix names for executables? #229

Closed
rcurtin opened this Issue Dec 29, 2014 · 5 comments

Projects

None yet

1 participant

@rcurtin
Member
rcurtin commented Dec 29, 2014

Reported by rcurtin on 22 Jan 42578220 05:28 UTC
MLPACK contains a lot of names of packages that could be possibly dangerous in the context of package managers: 'nbc', 'nca', and so forth; these names could already be in use for other applications.

A prefix is one way to solve this problem: 'mlpack_nbc', 'mlpack_nca', and so forth.
Another way to solve the problem is to create a standalone executable 'mlpack' which holds all the functionality in it: e.g. 'mlpack allknn --options...'. That executable could probably be generated entirely with CMake magic... maybe.

Does anyone have any opinions on how this should be handled?

Migrated-From: http://trac.research.cc.gatech.edu/fastlab/ticket/236

@rcurtin rcurtin self-assigned this Dec 29, 2014
@rcurtin rcurtin added this to the mlpack 1.1.0 milestone Dec 29, 2014
@rcurtin
Member
rcurtin commented Dec 30, 2014

Commented by nslagle on 5 Feb 42592394 02:22 UTC
A single executable would be fine so long as we dynamically load the functionality of particular modules (contrasted with one enormous static library containing everything.) Unfortunately, command-line users lose autocompletion (as far as I know).

A downside to prefixing executable names with '''mlpack_''' is the complication of autocompletion, though at least the feature remains available. We could consider postfixing, of course, though users might not know where to look for a list of available modules. (See the comment below.)

If the usage convention evolves to a GUI, we could name the modules anything we want, though an internal convention of shared names between the displayed module name and the shared library containing the module's functionality would be helpful.

Either path herds the various modules under the name '''mlpack''', probably a good thing.

@rcurtin
Member
rcurtin commented Dec 30, 2014

Commented by rcurtin on 8 Mar 42625602 23:51 UTC
It seems as though prefixing executable names will be the path of least pain (it does at least semi-preserve autocompletion). It should probably be an install-time CMake rule to rename all the binaries that way, otherwise internal CMake configuration could be a bit uglier (with mlpack_ everywhere) and irritation before install time (needing to type bin/mlpack_allknn in the build directory). I'll target this for 1.0.3 so it's done by then; the CMake-fu should be relatively straightforward. Unless someone else has a contrasting opinion of course...

@rcurtin
Member
rcurtin commented Dec 30, 2014

Commented by pararth on 23 May 43290592 11:12 UTC
It is a straightforward hack in the base folder CMakeLists.txt: override the add_executable function to set the PREFIX property to "mlpack_" of those targets whose name does not contain the prefix already. I have attached the diff to this ticket.

@rcurtin
Member
rcurtin commented Dec 30, 2014

Commented by rcurtin on 17 Jul 43290602 11:36 UTC
Hacking known function names so that they act differently isn't good for maintainability. The better solution is just to modify the relevant CMakeLists.txt files for each method. This ticket remains open because consensus hasn't been reached on what to do about this (so it's staying how it is for now).

@rcurtin
Member
rcurtin commented Dec 30, 2014

Commented by rcurtin on 5 Oct 44267444 16:31 UTC
We'll change to prefixed executables ("mlpack_nbc", etc.) when there is a minor version bump.

@rcurtin rcurtin removed their assignment Dec 30, 2014
@rcurtin rcurtin added D: easy and removed C: mlpack labels Jan 8, 2015
@rcurtin rcurtin added a commit that closed this issue Dec 23, 2015
@rcurtin rcurtin Fix #229. c0a1500
@rcurtin rcurtin closed this in c0a1500 Dec 23, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment