Generate source code to a subdirectory

[gchauvet]

This is a new proposal about C output destination : instead to have all generated files in the same root eiffel project folder, this patch create a subdirectory called ".gec".

The output executable file remains in the root directory.

[ebezault]

1. Use pathname instead of nested_pathname.
2. Use file_system.relative_parent_director instead of ".."
3. line 360: add a space before the parenthesis.
4. I understand that using folders whose name starts with . makes it hidden under Linux. But under Windows dealing with such folder names is never easy (it's already a pain to have to deal with .git, .ssh, etc.). So I would suggest that you make this subfolder name configurable (instead of being hard-coded in ET_C_GENERATOR). For example, we could have a command-line option in gec, something like --cc_directory. That way people could use the folder they want. Personally I would still keep the current working directory as default when this option is not specified. But, as we saw with the use of CMake, sometimes we can be surprised about what the majority of people want, and in that case they might want another default when the option is not specified.

[gchauvet]

Point 4: I'm agree with you, I'm reworking my patch to be backward compatible.
Note: I planned to modify ET_C_GENERATOR to manage C code only. I've noticed that script generation is in the same case you describe : it is built in ET_C_GENERATOR and recreated in GEC class. I'm wondering if all script generation must be migrated into GEC class ?

[ebezault]

The reason why I had put the script generation in ET_C_GENERATOR is two-fold:

1. In order to generate the scripts we need to know what has been generated by ET_C_GENERATOR.
2. Another C generator class may need different kinds of scripts.

Now I see that for a given C generator class, you might want to provide different ways to generate scripts. I'm not sure the script generation should be migrated to the GEC class though. The choice of the kind of script generation might be, but not the generation itself. I view the choice of the kind of script generation as a configuration/parameterization of the C generator class. Perhaps something like that:

my_c_generator.generate (system_name, my_script_generator)

Or even better if we want to be able to generate several kinds of scripts for the same C generation:

my_c_generator.add_script_generator (my_script_generator)
my_c_generator.generate (system_name)

Of course, the C generator should have a default script generator is none is provided. The default should probably generate the same kind of scripts as now. Going that way, ET_C_GENERATOR could have its 'make' with the default script generator, and another creation procedure 'make_with_script_generator'. If you add the command-line option --cmake to gec, then you would call this latter creation procedure with the corresponding CMake script generator:

create my_c_generator.make_with_script_generator (my_system, my_cmake_script_generator)
my_c_generator.generate (system_name)

[gchauvet]

As you mentioned, this is the best approach to use the delegation design pattern. We can imagine something like this :

• ET_SCRIPT_GENERATOR (abstract)
  • ET_BATCH_SCRIPT_GENERATOR (abstract : prepare data for a command line process)
    • ET_WINDOWS_BATCH_SCRIPT_GENERATOR (Target Windows OS)
    • ET_UNIX_BATCH_SCRIPT_GENERATOR (Target Unix OS)
  • ET_CMAKE_SCRIPT_GENERATOR (Target CMake subsystem for example)

For option switch:

gec --subsystem=batch|cmake (default batch) ...

IMO, we can also delegate execution plan to this delegate class.

[ebezault]

Shouldn't ET_CMAKE_GENERATOR inherit from ET_SCRIPT_GENERATOR?

[gchauvet]

Yes ET_CMAKE_GENERATOR inherit from ET_SCRIPT_GENERATOR.
The good name will be ET_CMAKE_SCRIPT_GENERATOR. I update my previous message.

[gchauvet]

I need to add cd {output directory} in Unix batch file, because system call create a new process "sh -c" who don't care of current working directory. I don't know if this issue occurs under Windows.

[gchauvet]

Changes are fine under Linux. I will test under Windows (seven) this weekend.
For script generators, I will work on in a separate pull request.