Added HPX::auto_wrap_main option

[kollanur]

Added the HPX::auto_wrap_main CMake target that excludes the need of including <hpx/hpx_main.hpp> header file in the main function to start HPX runtime when HPX::wrap_main is linked.

[StellarBot]

Can one of the admins verify this patch?

[hkaiser]

Could you add a test verifying this functionality, please? Perhaps here: https://github.com/STEllAR-GROUP/hpx/tree/master/tests/unit/init?

[hkaiser]

Some of the CIs are also failing because of an unused argument (https://app.circleci.com/pipelines/github/STEllAR-GROUP/hpx/18976/workflows/1db954bb-64fe-4130-81a8-15edc2925fbd/jobs/435313).

[kollanur]

Could you add a test verifying this functionality, please? Perhaps here: https://github.com/STEllAR-GROUP/hpx/tree/master/tests/unit/init?

Yes, I will do that.

[kollanur]

Some of the CIs are also failing because of an unused argument (https://app.circleci.com/pipelines/github/STEllAR-GROUP/hpx/18976/workflows/1db954bb-64fe-4130-81a8-15edc2925fbd/jobs/435313).

I will check those failures and fix them.

[hkaiser]

After thinking about this a bit more - we either should make this the default and make sure that the existing code still works (the one that has the #include <hpx/hpx_main.hpp>), or alternatively make it a buy-in on a application-per-application basis, preferrably by creating a dependency to a special target.

[kollanur]

Some of the CIs are also failing because of an unused argument (https://app.circleci.com/pipelines/github/STEllAR-GROUP/hpx/18976/workflows/1db954bb-64fe-4130-81a8-15edc2925fbd/jobs/435313).

I will check those failures and fix them.

Fixed it.

[kollanur]

After thinking about this a bit more - we either should make this the default and make sure that the existing code still works (the one that has the #include <hpx/hpx_main.hpp>), or alternatively make it a buy-in on a application-per-application basis, preferrably by creating a dependency to a special target.

I have made it default with the exisiting code still working.

[hkaiser]

After thinking about this a bit more - we either should make this the default and make sure that the existing code still works (the one that has the #include <hpx/hpx_main.hpp>), or alternatively make it a buy-in on a application-per-application basis, preferrably by creating a dependency to a special target.

I have made it default with the exisiting code still working.

It looks like that many tests are now failing. So making it the default wasn't a good idea after all :/

[hkaiser]

Very nice, LGTM, thanks!

[hkaiser]

@kollanur please disregard my last comment about using <hpx/modules/init_runtime_local.hpp>. I was focussing on the HPX_APPLICATION_STRING macro and missed that you needed <hpx/init.hpp> because of the calls to hpx::init. It is not sufficient to initialize HPX using hpx::local::init as this will not bring up the distributed runtime environment. I think you can safely roll back your latest commit. We can merge this PR once you do.

[kollanur]

@kollanur please disregard my last comment about using <hpx/modules/init_runtime_local.hpp>. I was focussing on the HPX_APPLICATION_STRING macro and missed that you needed <hpx/init.hpp> because of the calls to hpx::init. It is not sufficient to initialize HPX using hpx::local::init as this will not bring up the distributed runtime environment. I think you can safely roll back your latest commit. We can merge this PR once you do.

ok professor, got it.