CodeLite IDE

Hi Eran and Scott

I would like to try to implement the following request :
- Create project settings for all configurations (that is to say common to all configurations) : global

settings
- Allow the user to select to override the global settings, or to append the configuration settings to

the global settings.

Is it OK for you ?
If yes : I think I'm gonna begin to think in that direction :
- Create a new configuration called <global-settings> in ProjectSettings class (don(t know if I put it as a new class attribute, or if I add it to the actual map
- Modify the GetBuildConfiguration method to add a bool var to ask if we need the full (ie: merged with global_settings) settings or not.
- Modify method calling GetBuildConfiguration to get the good settings according to the context.

What do you think ?

Hi,

I would use this approach:

When creating new project, always create the global-settings (which is a configuration just like every other configuration) - to make it work properly all the templates needs to be updated as well.

Some questions:

Let take the 'Preprocessor' entry, now if a user wants to define a global __WINDOWS__ preprocessor, the fastest way is to define it in the <global-settings>.
Now assume that the project have 2 more configurations: Release and Debug

1) when user select 'Release' and switch to 'Compiler' tab, what shall we display in the 'preprocessor' entry? the combined value with the one from <global-settings> or just the configuration specific?

2) if we choose to display all, now when user clicks 'OK' or 'Apply' we need to perform some kind of parsing to make sure we dont save entries twice... or?
I think that the fastest way is that each configuration will display only the configuration specific, and only the makefile generator will use all.

Another thing:
I suggest that we define what can be set as in the <global-configuration>, we can start with:
- complier -> all entries (except for the check box which enables/disables the compiler)
- linker -> all entries (except for the check box which enables/disables the linker)
- resources -> all entries (except for the check box which enables/disables the resource compiler)

Eran

Hi Eran

eranif wrote:I would use this approach:
When creating new project, always create the global-settings (which is a configuration just like every other configuration) - to make it work properly all the templates needs to be updated as well.

Sure

eranif wrote: Some questions:
Let take the 'Preprocessor' entry, now if a user wants to define a global __WINDOWS__ preprocessor, the fastest way is to define it in the <global-settings>.
Now assume that the project have 2 more configurations: Release and Debug

1) when user select 'Release' and switch to 'Compiler' tab, what shall we display in the 'preprocessor' entry? the combined value with the one from <global-settings> or just the configuration specific?

2) if we choose to display all, now when user clicks 'OK' or 'Apply' we need to perform some kind of parsing to make sure we dont save entries twice... or?
I think that the fastest way is that each configuration will display only the configuration specific, and only the makefile generator will use all.

I agree, it will be like most of IDE I know.

eranif wrote:Another thing:
I suggest that we define what can be set as in the <global-configuration>, we can start with:
- complier -> all entries (except for the check box which enables/disables the compiler)
- linker -> all entries (except for the check box which enables/disables the linker)
- resources -> all entries (except for the check box which enables/disables the resource compiler)

Once again, I agree, but this remarks make me ask myself about the General tab : I don't know if the compiler can be changed without side effects (and maybe other inputs...)

I continue to think about it before doing everything, let me know about your point of view.
As I understood, I can go on it

ofc u can

Eran

Hi Eran

After some days, I think putting the global-settings outside the map is better because of :
- We can't remove it
- It's easier and faster to use a named object (global-settings) for merging operations (and maybe more), instead of looking into the map each time we need it.
- If there must be a global-settings everytime (even if it isn't used, ie : empty), we must find a container corresponding (the object directly is the best solution for it, in my point of view).
- No need to change all project already created bi CL, because the global-settings will created automaticaly empty, and saved during project save.

What do you think ? Do I miss something (regarding my knowledge of CL sources, maybe about makefile generation) ?

Hi jfouche,

I gave some thoughts for how to implement it, and this is what I think (got some time in the train on the way to work):

UI:
. In the project settings dialog, I would add a new entry in 'configuration selection' combo box which contains "all configurations"
. When the new entry is selected (i.e. "all configurations"), the projct settings will display a new wxNotebook with 3 pages:
. Compiler
. Linker
. Resource
The above can be done pretty easy since the entire UI is all contained in a wxNotebook, so we can simply hide it and display the new one.

Backend:
. New class 'GlobalConfiguration' which derives from SerializedObject and contain the information from the global settings
. An instance of this class is kept as member in the ProjectSettings class and should be considered in the constructor / ToXml methods

Makefile generator:
. The only modification needed is to adjust the the
Method: BuilderGnuMake::CreateConfigVariables: it should use the global configuration paths/includes/libraries for the following makefile variables:
. LinkOptions
. IncludePath
. RcIncludePath
. Libs
. LibPath
Note to consider: location of libraries or include path is important in some cases, we shuold also add a checkbox in the UI to indicate whether
the global include/lib path/linker options/compiler options should appear before or after the configuration settings.


Thats it for now, let me know what do you think or if you need help etc.

Eran

Hi Eran

eranif wrote:Backend:
. New class 'GlobalConfiguration' which derives from SerializedObject and contain the information from the global settings

I think I will not do this way. I will create a ProjectGlobalConfiguration which derives from ConfObject, containing all global informations. I will change BuildConfig to derive from ProjectGlobalConfiguration to not duplicate loading / saving global settings : it will contain global configuration (is : options, include paths, ...) and the ones existing. So I'm gonna move some attributes / methods from BuildConfig to ProjectGlobalConfiguration.

jfouche wrote:I will create a ProjectGlobalConfiguration which derives from ConfObject,

ConfObject is kinda deprecated class, please use SerializedObject in new code

jfouche wrote:I will change BuildConfig to derive from ProjectGlobalConfiguration

I fail to see the relation between global configuration and build configuration except for the fact that both has same attributes, I would remove all the code from the build-configuration that handles the linker/compiler/resource compiler and place it into a separate class (e.g. BuildConfCommon) and keep one instance of it as member of BuildConf and another instance as member of the project settings - this sounds more logical to me.

Eran

eranif wrote:ConfObject is kinda deprecated class, please use SerializedObject in new code

Well, It will beak project compatibility because SerializedObject will create a <SerializedObject> xml node.
Moreover, I'm not sure that SerializedObject can manage child nodes...

jfouche wrote:Well, It will beak project compatibility because SerializedObject will create a <SerializedObject> xml node.

Correct, I forgot about this

jfouche wrote:Moreover, I'm not sure that SerializedObject can manage child nodes...

it can, Archive object is capable of storing other SerializedObject (assuming that this is what you meant)

I still supports my opinion that we should create a separate class for the global configuration - but as you mentioned, it should be deriving from ConfObject and not from SerializedObject

Eran