Regression: Makefile broken for libboinc_graphics2

[brevilo]

Describe the bug Regression in #2149: Makefile broken for libboinc_graphics2

If you must build libboinc_graphics2.a using a make file, you must modify the make file to first compile api/MultiGPUMig.defs, which will create the files MultiGPUMig.h, MultiGPUMigServer.c, MultiGPUMigServer.h and MultiGPUMigUser.c.

Steps To Reproduce

1. Configure BOINC with --enable-libraries (no server, client, manager) and use make to build it.

Expected behavior A successful build

System Information

• OS: macOS
• BOINC Version: master

I consider this a known regression and I don't understand why the PR got merged in the first place. If the Makefile is known to be broken and solution was known as well, then why wasn't the Makefile updated as part of the PR?

This issue also shows where integration testing is still lacking coverage.

[SETIguy]

I attempted to raise these issues a very long time ago and was told that the BOINC application libraries were not meant to be installed (or used as shared). An even larger problem would be that the header names are too generic for them to be safely installed in one of the standard directories without colliding with existing files. An architecture change to put the files in ${prefix}/include/boinc would help.

On Tue, Feb 25, 2020 at 4:55 AM brevilo [email protected] wrote:

Describe the bug Regression in #2149 https://github.com/BOINC/boinc/pull/2149: Makefile broken for libboinc_graphics2

If you must build libboinc_graphics2.a using a make file, you must modify the make file to first compile api/MultiGPUMig.defs, which will create the files MultiGPUMig.h, MultiGPUMigServer.c, MultiGPUMigServer.h and MultiGPUMigUser.c.

Steps To Reproduce

1. Configure BOINC with --enable-libraries (no server, client, manager) and use make to build it.

Expected behavior A successful build

System Information

• OS: macOS
• BOINC Version: master

I consider this a known regression and I don't understand why the PR got merged in the first place. If the Makefile is known to be broken, why wasn't it updated as part of the PR?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/BOINC/boinc/issues/3469?email_source=notifications&email_token=ACS5ZMVNRCUD7GTHY4ELSOTREUIKXA5CNFSM4K3IBFR2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4IQB44HQ, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACS5ZMQDMMOEJJE7EIUP3A3REUIKXANCNFSM4K3IBFRQ .

-- Eric Korpela [email protected] AST:7731^29u18e3

[CharlieFenton]

An architecture change to put the files in ${prefix}/include/boinc would help.

That would of course require corresponding changes to the Xcode project

[brevilo]

Sorry Eric, I don't follow. This issue is about building the BOINC libs in order to build science/screensaver apps that depend on them. They simply can't be built right now using the configure/make infrastructure because that (still) lacks the necessary steps to build/produce said derived files. In this context no files would be installed in any "standard directory" but in the (temporary) prefix provided. There won't be any collisions (this isn't about the notorious config.h). I also don't see why this would need a change to the Xcode project. An extension (as suggested by Charlie in #2149) to the Makefile should be sufficient.

It's a known issue that, according to #2149, was meant to be resolved in a second PR - but that never came.