[anjuta-devel] New AnjutaProcess object

[Sébastien Granjoux <seb sfo free fr>]

Hi Lucas,


I propose a new AnjutaProcess object to keep all information about a 
command:

AnjutaProcess*  anjuta_process_new ();
void            anjuta_process_free (AnjutaProcess *proc);

void            anjuta_process_set_work_directory (AnjutaProcess *proc);
const gchar*    anjuta_process_get_work_directory (AnjutaProcess *proc);

void            anjuta_process_set_env (AnjutaProcess *proc,
                                        const gchar *name,
                                        const gchar *value);
const gchar*    anjuta_process_get_env (AnjutaProcess *proc,
                                        const gchar *name);
gchar **        anjuta_process_list_end (AnjutaProcess *proc);

void            anjuta_process_insert_arg (AnjutaProcess *proc,
                                           gint pos,
                                           const gchar *value);
void            anjuta_process_remove_arg (AnjutaProcess *proc,
                                           gint pos);
const gchar*    anjuta_process_get_arg (AnjutaProcess *proc,
                                           gint pos);
gint            anjuta_process_get_arg_count (AnjutaProcess *proc);
gchar **        anjuta_process_list_arg (AnjutaProcess *proc);


1. This object could replace the gchar **dirp, gchar ***argvp, gchar 
***envp argument of ianjuta_environment_override.

2. I have put here the minimum set of function. Do you think it is 
useful to have a particular set of function to set and get the first 
argument which is the program name?

3. You could have some additional functions like
void            anjuta_process_replace_arg (AnjutaProcess *proc,
                                            gint pos,
                                            const gchar *value);

4. list_arg and list_env could return a constant arry of constant string 
so the caller don't have to use g_strfreev.

5. You could need a function to get a escaped command line by example
gchar*          anjuta_process_get_command_line (AnjutaProcess *proc);

6. I don't really like the name AnjutaProcess, as it's not really a 
process at this time just a array of arguments and environment variable. 
AnjutaCommand would be better but it's already used so AnjutaProgram? or 
do you have a better idea?

7. Obviously one step further, could be to include a run function in 
this object. It seems that all plugins using 
ienvironment_anjuta_override use anjuta_launcher, so this object could 
provide a function to run the command directly. list_arg and list_env 
function will not be necessary in this case. It is possible to make it a 
virtual function too, allowing even more flexibility.

8. I haven't added to ianjuta_environment but we could add an additional 
type argument telling which kind of program it is (configure, debugger, 
compile, built, install, clean...). The environment plugin can use it to 
avoid checking the program name. On the other hand if the environment 
plugin cannot recognize the program, changing the argument is quite 
hazardous. That's why I haven't done it.

9. It doesn't completely solve your issue with parsing the command line. 
But as we don't need to escape character here, it shouldn't be too 
difficult to list all arguments looking for CFLAGS= by example and 
modifying it. I have tried to find a way to make this more convenient 
but it's difficult because some programs use a prefix directly followed 
by a name without an equal sign. Note that inserting argument in the 
middle could be annoying because sometimes the prefix and the value is 
separated by a space so it will end in 2 different arguments.



Else for the issue about the configure command line modified by the 
standard build plugin and the environment plugin. I think the build 
plugin can create such object and use the override function to get the 
argument needed by the environment plugin. In the other direction, we 
can add a "changed" signal to the environment plugin emitted each time 
some configuration is updated. The build plugin will listen to this 
signal and run again the override function to update the command line 
displayed in the dialog.

Perhaps we can find something better. At least this behavior is quite 
general and you don't need to implement new function in the environment 
plugin.


Regards,

Sébastien