Compiler path

The class overrides compiler path by using the one from the command line. The class is moved from "framework/environment/tools" to "Eiffel/interface/shared".

[Manus, 2017-06-22 14:54:41]

https://codereview.appspot.com/328750043/diff/1/es_eiffel_layout.e
File es_eiffel_layout.e (right):

https://codereview.appspot.com/328750043/diff/1/es_eiffel_layout.e#newcode39
es_eiffel_layout.e:39: create Result.make_from_string ((create
{ARGUMENTS_32}).command_name)
Doesn't command_name includes the full executable path? Here we just want the
executable name.

[alexk_es, 2017-06-22 15:00:07]

> Doesn't command_name includes the full executable path? Here we just want the
> executable name.

The comment of `ec_command_name` says:

   Absolute path to `ec'.

so everything should be fine.

[Manus, 2017-06-22 15:21:54]

> The comment of `ec_command_name` says:
> 
>    Absolute path to `ec'.
> 
> so everything should be fine.

Indeed, I initially thought it was only doing the name since of its usage of
EC_NAME in EIFFEL_ENV.

[Manus, 2017-06-22 16:31:07]

Are we all in agreement to drop the usage of EC_NAME for the compiler! Should we
ask our users to find out who are using it, if they are using it just in
conjunction with estudio?

We should change EIFFEL_ENV, EC_EIFFEL_LAYOUT and ES_EIFFEL_LAYOUT.

Currently EC_EIFFEL_LAYOUT is only created to avoid a call on Void-target in
EIFFEL_LAYOUT if one does not set it (This is required because for some tools it
was difficult to change the way initialization worked out). So we could merge
really ES_EIFFEL_LAYOUT into EC_EIFFEL_LAYOUT. Then in
{EIFFEL_ENV}.ec_command_name, we have the version you just put in
ES_EIFFEL_LAYOUT.

Now we just need to copy the existing implementation of `ec_command_name` to
ESTUDIO_EIFFEL_LAYOUT to preserve the former behavior.

[alexk_es, 2017-06-22 17:12:16]

> Are we all in agreement to drop the usage of EC_NAME for the compiler! Should
we
> ask our users to find out who are using it, if they are using it just in
> conjunction with estudio?

This is part of "framework", not "library", so no users should be using these
classes.

> Currently EC_EIFFEL_LAYOUT is only created to avoid a call on Void-target in
> EIFFEL_LAYOUT if one does not set it.

There is no reason to use EC_EIFFEL_LAYOUT in this case. EIFFEL_ENV will do.

> ... we could merge really ES_EIFFEL_LAYOUT into EC_EIFFEL_LAYOUT.

Yes, and get rid of the override in the compiler by removing EC_EIFFEL_LAYOUT
from "framework".

> Now we just need to copy the existing implementation of `ec_command_name` to
> ESTUDIO_EIFFEL_LAYOUT to preserve the former behavior.

Do you mean ES_EIFFEL_LAYOUT?

[jfiat_es, 2017-06-22 17:29:19]

On 2017/06/22 17:12:16, alexk_es wrote:
> > Are we all in agreement to drop the usage of EC_NAME for the compiler!
Should
> we
> > ask our users to find out who are using it, if they are using it just in
> > conjunction with estudio?
> 
> This is part of "framework", not "library", so no users should be using these
> classes.
> 
> > Currently EC_EIFFEL_LAYOUT is only created to avoid a call on Void-target in
> > EIFFEL_LAYOUT if one does not set it.
> 
> There is no reason to use EC_EIFFEL_LAYOUT in this case. EIFFEL_ENV will do.
> 
> > ... we could merge really ES_EIFFEL_LAYOUT into EC_EIFFEL_LAYOUT.
> 
> Yes, and get rid of the override in the compiler by removing EC_EIFFEL_LAYOUT
> from "framework".
> 
> > Now we just need to copy the existing implementation of `ec_command_name` to
> > ESTUDIO_EIFFEL_LAYOUT to preserve the former behavior.
> 
> Do you mean ES_EIFFEL_LAYOUT?

About EC_NAME .. it may be used in some scripts.
I remember in the past I used this for bootstrapping, but I don't remember the
details, and neither if this is still used.

But, why would we gain to remove EC_NAME ? Simplification?

[jfiat_es, 2017-06-22 17:30:23]

On 2017/06/22 17:29:19, jfiat_es wrote:
> On 2017/06/22 17:12:16, alexk_es wrote:
> > > Are we all in agreement to drop the usage of EC_NAME for the compiler!
> Should
> > we
> > > ask our users to find out who are using it, if they are using it just in
> > > conjunction with estudio?
> > 
> > This is part of "framework", not "library", so no users should be using
these
> > classes.
> > 
> > > Currently EC_EIFFEL_LAYOUT is only created to avoid a call on Void-target
in
> > > EIFFEL_LAYOUT if one does not set it.
> > 
> > There is no reason to use EC_EIFFEL_LAYOUT in this case. EIFFEL_ENV will do.
> > 
> > > ... we could merge really ES_EIFFEL_LAYOUT into EC_EIFFEL_LAYOUT.
> > 
> > Yes, and get rid of the override in the compiler by removing
EC_EIFFEL_LAYOUT
> > from "framework".
> > 
> > > Now we just need to copy the existing implementation of `ec_command_name`
to
> > > ESTUDIO_EIFFEL_LAYOUT to preserve the former behavior.
> > 
> > Do you mean ES_EIFFEL_LAYOUT?
> 
> About EC_NAME .. it may be used in some scripts.
> I remember in the past I used this for bootstrapping, but I don't remember the
> details, and neither if this is still used.
> 
> But, why would we gain to remove EC_NAME ? Simplification?

Indeed EC_NAME is still used in the geant scripts under
Src/scripts/geant/deliv.eant.

[alexk_es, 2017-06-22 17:32:31]

> But, why would we gain to remove EC_NAME ? Simplification?

I never mentioned removal of EC_NAME. The idea is to distinguish 2 cases:
1) compiler: use command name (of the current executable) all the time;
2) anything else: use EC_NAME or whatever logic is currently used, but not the
command name (of the current executable).