[one-cmds] Revisit policy of getting backend list

[mhs4670go]

What

Let's revisit the policy of getting backend lists.

Why

This is the current policy where the backend list is fetched.

https://github.com/Samsung/ONE/blob/dbad91189fd3e7b448392d2b1af25577b64d7bcd/compiler/one-cmds/one-codegen#L37-L55

https://github.com/Samsung/ONE/blob/dbad91189fd3e7b448392d2b1af25577b64d7bcd/compiler/one-cmds/one-codegen#L61-L64

If -b dummy is given, dummy-codegen or dummy-profile should be in the directory under backends. Any driver with the same name can be a candidate.

But, what if we want to use the same driver name with different backends? It'd be difficult to choose which driver we should prefer. So, one of the solution of this problem is to change the current policy where users can give the directory name for getting backend list.

For example, this is the tree of the directory.

$ tree /usr/share/one/backends
/usr/share/one/backends
└── old-backends
     ├── bin
     │   ├── my-compile
     │   └── my-profile
     └── lib
└── new-backends
     ├── bin
     │   ├── my-compile
     │   └── my-profile
     └── lib

Then, we could use them by -b old-backends and -b new-backends.

@seanshpark @jyoungyun @lemmaa @ejjeong @parjong

[seanshpark]

IIUC, from current design, my-compile in new-backends should be not my-compile but use different name like mynew-backends. Q) why do we want to use my-compile for new-backends ?

[mhs4670go]

@seanshpark oh, I think it needs more explanation. I just wanted to say that the directory becomes matter rather than inside driver name. Actually, then, the prefix becomes secondary. The file just should have suffix *-comile, *-profile.

But, we can force them to follow its directory name. For example, if directory is old, the inside driver should have suffix 'old' like old-compile.

[seanshpark]

But, we can force them to follow its directory name. For example, if directory is old, the inside driver should have suffix 'old' like old-compile.

Ah, OK :)

[lemmaa]

... The file just should have suffix *-comile, *-profile.

But, we can force them to follow its directory name. For example, if directory is old, the inside driver should have suffix old like old-compile.

It doesn't seem that simple for 3rd party solutions. How about adding a mapping file, something like .toolchain-map, as an option in the directory in case this rule is not followed. Of course, this could be done as a separate step from the current approach.

└── new-backends
     ├── .toolchain-map
     ├── bin
     │   ├── aaa-compiler
     │   └── my-profile
     ├── tools
     │   └── infer
     └── lib

Example of .toolchain-map

#
compile=./bin/aaa-compiler
profile=./tools/perf
infer=./tools/infer

[mhs4670go]

@lemmaa Seems good idea from the point of view; explicit is better than implicit.

It doesn't seem that simple for 3rd party solutions.

When it comes to this issue's approach, since third party is often not being installed under /usr/share/one/backends directory in the first place, they may use our tool with symlink to that place.

Anyway, having only one policy will make easier maintenance. After having some discussion, I'll choose one of them.

[lemmaa]

When it comes to this issue's approach, since third party is often not being installed under /usr/share/one/backends directory in the first place, they may use our tool with symlink to that place.

My guess is that there should be a separate backend package for ONE that serves to link, this is not just a symlink, their installed toolchain. In that case, the .toolchain-map file can be used to deliver the full path information of the corresponding executable file. :)

[jyoungyun]

What is the appropriate module to install the .toolchain-map file in the backends directory?

[lemmaa]

What is the appropriate module to install the .toolchain-map file in the backends directory?

In the case of the backend we make, it would be a natural choice for the corresponding backend package to include it.

In the case of a toolchain made by a third party, I think you asked this, it would be a natural choice to have a separate package such as ONE-*-connector or ONE-*-helper that connects it, separately installed 3rd party toolchain, as a backend of ONE Compiler. In this case, ONE-*-connector, ONE-*-helper can be made by them or by us.