patch for one-step makefile

[hops]

As mentioned in this thread here is a patch for a one step makefile.
Its implemented as an additional build system so includes mods for supporting that, Using the selected build system rather than the various mappings to the single
build system result used previously and storing the selected build system for restarts.

The new build system is a subclass of builder_gnumake so theres some refactoring there also to separate construction of build and clean rules.
there also some small number of typo fixes...

[eranif]

Hi Hops,

I was not able to apply your patch it fails on builder_gnumake.cpp due to some changed I made recently.
I will be very much appreciate if you could re-generate the patch using latest SVN trunk

Thanks,
Eran

[hops]

OK - I'm out of touch for a few days from today through to about tuesday...
I'll resync and regen a new patchfile when I get back - repost on same discussion thread.

[hops]

Managed to fit it in tonight - heres the patchfile against r3623.

[eranif]

Managed to fit it in tonight - heres the patchfile against r3623.

Great, I will give it another try a soon as I will finish another FR you posted (allow to specify custom 'Tasks')

Eran

[eranif]

Hi,

I applied your patch, with some modifications.
I changed the concept of active builder to become a property of the 'builder' and it is also saved in the XML file.

2 questions:
- Why dont u name the new buidler as 'Cobra builder'?
- Do you need the 'Jobs' fields in the GUI? - if not can I remove them?

Also, I changed the code a bit to make it simpler - this is WIP.

The code is not committed yet, it needs some further testing to make sure nothing has broken.
Eran

[hops]

good -O

I changed the concept of active builder to become a property of the 'builder' and it is also saved in the XML file.

Ok - I dunno what that means but I'm sure its an improvement

Why dont u name the new builder as 'Cobra builder'?

Because while I did the new builder to support cobra
thats not the only thing it would work for - It'll work for any system that had a one step transform from a bunch of source files to an executable
(e.g various basic compilers, Java, C#). Its just a simple variant on the existing 2 step builder ( source -> objs -> executable)

- Do you need the 'Jobs' fields in the GUI? - if not can I remove them?

Umm - is that with reference to the commented adding an 'unspecified' value to the jobs/njobs combobox?
cobra (compiler) has a different setting for parallelising its compilation (switch passed to the cobra builder/compiler invocation) so its not required as such..
It'd probably be useful if that field could be accessed as (another) macro so a command line could be built using it but the idea
is/was to provide a setting that meant ignore this field ( and dont generate a switch value for it either) so that an alternative build tool than gmake
( that doesnt use the -j switch for that) could be specified.

Actually,for this a more general fix would be for that field to include both the switch value and the number of processes ( rather than just the number of processes)
e.g. '-j 2' rather than currently '2' say
That way for a gmake based builder it would work correctly as now but if you wished to specify a different builder (like cobra) you could specify the correct switch for that
or leave it out altogether
( I think I alluded to this in my original discussion posting in attempting to specify cobra as a builder but failing cos the CL code always added a '-j' switch)

perhaps should provide another 'generic builder' (+ GUI screen) that had no gmake dependencies and did no additional additions to its specified executable and args but only provided a way to access the list of (source ) files in the project and just (attempted to) run the provided build commandline..

..
Whatever changes you think necessary/reasonable are fine - I'll come back with something if they dont fly for me
What regression testing (nothing has broken) do you do?
If you described this for contributors ( or better automated it) you might save yourself some checking overhead ....

[eranif]

Actually,for this a more general fix would be for that field to include both the switch value and the number of processes ( rather than just the number of processes)
e.g. '-j 2' rather than currently '2' say
That way for a gmake based builder it would work correctly as now but if you wished to specify a different builder (like cobra) you could specify the correct switch for that
or leave it out altogether

Ok I will fix this to become more generic

What regression testing (nothing has broken) do you do?
If you described this for contributors ( or better automated it) you might save yourself some checking overhead ....

Unfortunately I got no automated testing for this part.

So what I did was to updated my local copy with the new changes, and then loaded various workspaces which should work out of the box. I make sure that the current builder is the old one, unless specified otherwise (BTW, i added a little message in the status bar which indicates which builder is currently in use)

I compiled various project types (DLLs, EXE, libraries) - the only drawbacks that I found were:
- the GUI was not in sync with the actual builder used
- Settings were not saved properly to the disk

However, I am using this build for couple of days now, with no issues at all - so I think it is safe to say that the change went smooth.

Eran