Enabling parallel build on windows

[giuliof]

Hello,
I'm currently having an issue with Eclipse CDT version 2023-03 on windows and some "C Managed Build" projects. In the C/C++ Build > Behavior tab I have "Enable parallel build" checked with "Use optimal jobs". But when the project is built, files are processed sequentially and complete operation takes over one minute.
If I select "Use unlimited jobs" the build operation is run in parallel and takes only few seconds.

I have no issue on Linux platform, nor on an older Eclipse version, CDT 8.3.0, where some of the projects were created.

I may fall back to "Use unlimited jobs" option, but I feel there is a most efficient way to solve this problem.

[jantje]

My 2cent.
I have not seen this behaviour on windows and I use parallel build for all my testing.
So I would assume this is a new bug (very unlikely) or a very specific case (hardware/project)

[jonahgraham]

Can you share the generated makefiles from CDT 8.3 and current CDT on Linux and Windows? I can look to see if I can see something unusual, but as -j24 is being passed it sounds like the CDT part is doing the right thing.

The other things to try, and if it leads anywhere we can look at making changes in CDT:

1. Run make -j24 all from a command line to ensure that Eclipse CDT isn't modifying the environment in some unusual way
2. Try a space between -j and 24 in case the command line isn't being parsed as expected
3. Confirm that in CDT 8.3 that it is running make -j24 all as well and nothing else changed?

TBH I am grasping at straws a little.

Feel free to send them to be by email if you would rather they are not made public (jonah at https://kichwacoders.com).

[jantje]

In my environment Managed build has a space between -j and the maximum number of parallel jobs. Gnu make requires a space.
https://www.gnu.org/software/make/manual/make.html states

As you have a special make command can you provide the project properties->C++ build settings

[giuliof]

Can you share the generated makefiles from CDT 8.3 and current CDT on Linux and Windows? I can look to see if I can see something unusual, but as -j24 is being passed it sounds like the CDT part is doing the right thing.

@jonahgraham Following this idea, I tried to compare the makefiles generated by the two eclipse.
I found that the older one generates a makefile containing this line

all: myproject.elf secondary-outputs

Which makes sense. While newer one generates this:

all:
     +@$(MAKE) --no-print-directory main-build && $(MAKE) --no-print-directory post-build

# Other things...
main-build: myproject.elf secondary-outputs

And obviously, by replacing the nested make call with correct dependencies in all target, it works like a charm. I wonder why newer eclipse changes the all: target like this.

Anyways, for completeness, I've also tried to:

1. manually run make from CMD,
2. add a space between -j and jobs number,
3. and check -j presence in CDT 8.3

... same behavior

[jonahgraham]

The change of that line was to fix Bug 573502

So, simply changing it back will regress another case.

What I don't understand is why that only affects Windows and not Linux.

My guess there has to do with inheritance rules on parallel with the $(MAKE). The idea of using $(MAKE) is to ensure child makes use the same version. My guess (without researching) is that on Linux the various instances of make can communicate to respect the top-level -j24, but on Windows they can't and play it safe by having no parallel on child makes. So when you do -j unlimited, the child makes on Windows can do that because they don't need to coordinate.

[jantje]

Workaround change target all to main-build (that will disable pre and post processing)

My guess there has to do with inheritance rules on parallel with the $(MAKE).

I had the same guess. I have seen many differences between make implementations and this example uses 2 things I do not expect make world to see as mainstream (the j24 and @$(MAKE) --no-print-directory main-build )
Different behaviours are to be expected

[jonahgraham]

My guess

That seems to be correct - the documentation says:

If you set it to some numeric value ‘N’ and your operating system supports it (most any UNIX system will; others typically won’t), the parent make and all the sub-makes will communicate to ensure that there are only ‘N’ jobs running at the same time between them all.

That leaves us with a bug to fix, the fix of Bug 573502 caused this regression on Windows.

[jonahgraham]

I have raised bug #410

[jonahgraham]

The final conclusion was that the version of Make the OP was using was out of date and newer versions work well. Thank you everyone for your input here!