[PATCH] Create a "debug" build profile for use with Buildbot

[umccullough]

The attached patch creates a "debug" build profile (in a newly-added DebugBuildProfiles jamfile) while also fixing an issue that is preventing building with DEBUG=1 on a 64bit host.

This build profile will be used with Buildbot to continually test compilation of (most of) the tree with DEBUG=1 set.

During my testing, I discovered a few areas in the tree where targets failed to compile with DEBUG=1 and have added these as exceptions in the profile. These should eventually be fixed and the exceptions removed.

Patch was created with "git format-patch --stdout", please let me know if this is an issue.

[umccullough]

patch to add debug profile and fix build on 64bit host

[umccullough]

Oops, there is one more subdirectory that doesn't compile with DEBUG=1 under gcc4 (I missed that during my testing) - I'll add an additional patch for that.

[umccullough]

This should be applied after the other patch to add another subdirectory exception for gcc4 builds

[mmadia]

What happens when jam -q @debug is run with HAIKU_ADD_ALTERNATIVE_GCC_LIBS ?= 1 ; ?

Does the alternative_system_libs.zip get compiled with debugging?

[Disreali]

Has this been tested when building on a Haiku host?

[umccullough]

Replying to mmadia:

What happens when jam -q @debug is run with HAIKU_ADD_ALTERNATIVE_GCC_LIBS ?= 1 ; ?

Does the alternative_system_libs.zip get compiled with debugging?

In theory, it should work, and they should include debug code I think (since the variable is set for the directory structure and all targets compiled from within in)... but I'd probably have to increase the image size again.

I'll test this out when I get a chance (probably tomorrow).

@Disreali:

Haven't tested it - and we don't have a buildbot slave on a Haiku host yet either. It should work I think - and I'll perhaps start setting up a buildslave for this soon.

[bonefish]

Replying to umccullough:

Replying to mmadia:

What happens when jam -q @debug is run with HAIKU_ADD_ALTERNATIVE_GCC_LIBS ?= 1 ; ?

Does the alternative_system_libs.zip get compiled with debugging?

In theory, it should work, and they should include debug code I think (since the variable is set for the directory structure and all targets compiled from within in)...

I doubt that. The alternative gcc part is built in a sub-jam and besides the list of optional packages nothing is propagated to it.

I'm undecided whether it is worth having this build profile at all. The list of DEBUG exceptions could as well be moved to BuildSetup and then the same effect could be reached by running

DEBUG=1 HAIKU_IMAGE_NAME=haiku-debug.image HAIKU_IMAGE_SIZE=650 jam @image

Since I can't think of anyone being interested in building such a debug image that seems good enough to me.

The BBlockCache fix looks OK and could be applied regardless.

[umccullough]

Replying to bonefish:

I doubt that. The alternative gcc part is built in a sub-jam and besides the list of optional packages nothing is propagated to it.

Hmm... would using "DEBUG=1 jam @image" fix that issue?

Since I can't think of anyone being interested in building such a debug image that seems good enough to me.

Ok. I've already got additional patches for fixing several of those exceptions... should I just create a new ticket for all of those?

The BBlockCache fix looks OK and could be applied regardless.

Can someone apply that for me? :)

[bonefish]

Replying to umccullough:

Replying to bonefish:

I doubt that. The alternative gcc part is built in a sub-jam and besides the list of optional packages nothing is propagated to it.

Hmm... would using "DEBUG=1 jam @image" fix that issue?

Yep. Though, obviously, the calling jam's DEBUG variable value should be propagated.

Ok. I've already got additional patches for fixing several of those exceptions... should I just create a new ticket for all of those?

I guess attaching them to this ticket is fine.

The BBlockCache fix looks OK and could be applied regardless.

Can someone apply that for me? :)

I don't have much time ATM and my tree is in a rather messy state, so if there's any other taker, that would go faster.

[umccullough]

Separate patch for adding the debug profile from the 64bit build issue

[umccullough]

Fix debug build on 64bit host

[umccullough]

I broke the original patch into two so that the 64bit debug fix can be applied separately.

[mmadia]

Applied debug_build_on_64bit.patch in hrev43545, based on mailing list feedback.

[umccullough]

Fix the mouse preferences debug build

[umccullough]

Fix media server debug build

[umccullough]

Fix usb_midi debug build

[umccullough]

Fix AutoMounter debug build

[umccullough]

Fix BSnow debug build

[umccullough]

Fix OpenSound debug build

[umccullough]

Attached a few patches to fix various debug builds - I'm sure some of these possibly aren't the best way to fix the problems, but I tried :)

I'll work on a better patch to exclude the rest of the misbehaving subdirs per Ingo's suggestion.

[bonefish]

I forgot to mention: For the third-party code with errors I would simply disable debugging (i.e. override DEBUG) in the respective Jamfiles.

[umccullough]

Fix canna input method debug build

[umccullough]

Replying to bonefish:

I forgot to mention: For the third-party code with errors I would simply disable debugging (i.e. override DEBUG) in the respective Jamfiles.

OK - I think all the patches I've supplied so far are either our own code, or code that I doubt we plan to replace again (canna input method for example).

Once I've fixed as many as I feel are within my means, I'll submit the jamfile patches you proposed.

[mmadia]

Fix-copy-paste-error-in-mouse-preferences-so-it-will.patch applied in hrev43550. Can anyone comment on the other patches?

[umccullough]

Fix cortex debug build

[umccullough]

Fix PDF print driver debug build

[umccullough]

Fix another mouse pref issue for GCC4 debug build (sorry I didn't catch this one earlier)

[umccullough]

Replying to bonefish:

I forgot to mention: For the third-party code with errors I would simply disable debugging (i.e. override DEBUG) in the respective Jamfiles.

I wasn't sure how to do this - so the last patch I attached here has all of the logic in BuildSetup still.

The 3rd party dirs we likely won't mess with are the two printing libs and the ffmpeg stuff I guess?

[bonefish]

Replying to umccullough:

Replying to bonefish:

I forgot to mention: For the third-party code with errors I would simply disable debugging (i.e. override DEBUG) in the respective Jamfiles.

I wasn't sure how to do this - so the last patch I attached here has all of the logic in BuildSetup still.

Just add a DEBUG = 0 ; line in the respective Jamfiles somewhere between the SubDir and the rule invocation for the first target. Ideally with a comment.

The 3rd party dirs we likely won't mess with are the two printing libs and the ffmpeg stuff I guess?

With 3rd party I mean code that is still developed outside of our repository and might be updated or outsourced eventually. Hence I would consider libprint "absorbed", but yes to the others. Moreover coreutils and ctags fall into my 3rd party category. tcpdump as well, though it seems to have been customized quite a bit, so the debug code should probably better be fixed.

Regarding the patches:

Fix-implicit-void-cast-in-usb_midi-debug-code.patch
Fix-warning-in-AutoMounter-debug-code.patch
Fix-warning-in-BSnow-debug-code.patch
Fix-bad-debug-print-in-canna.patch
Fix-various-issues-in-cortex-debug-code.patch
Fix-PDF-print-driver-debug-code.patch
Fix-another-mouse-preference-issue-specific-to-gcc4-.patch

Signed-off-by: Ingo Weinhold <ingo_weinhold@gmx.de>

Avoid-warning-in-debug-code-for-media-server.patch: What's the warning and why does the patch fix it? Looks completely equivalent to me.

Fix-warnings-in-OpenSound-debug-code.patch: First part OK, the second part, just like the previous patch, I don't understand.

PS: It would really be nice to have that "Apply Patch" button in Trac.

[umccullough]

Replying to bonefish:

Just add a DEBUG = 0 ; line in the respective Jamfiles somewhere between the SubDir and the rule invocation for the first target. Ideally with a comment.

OK, Will do.

With 3rd party I mean code that is still developed outside of our repository and might be updated or outsourced eventually. Hence I would consider libprint "absorbed", but yes to the others. Moreover coreutils and ctags fall into my 3rd party category. tcpdump as well, though it seems to have been customized quite a bit, so the debug code should probably better be fixed.

Ah, that makes sense.

Avoid-warning-in-debug-code-for-media-server.patch: What's the warning and why does the patch fix it? Looks completely equivalent to me.

Fix-warnings-in-OpenSound-debug-code.patch: First part OK, the second part, just like the previous patch, I don't understand.

Right, these two were a bit subtle.

The warning was about an unused variable. Apparently these variables are only initialized in an "#ifdef DEBUG" block, but further down, they are only used in a TRACE() line... which I suppose may not always be enabled with DEBUG.

By moving the initialization below the definition, the "unused variable" warning seemed to go away. Is there a better suggestion?

Quick reference links:

​http://cgit.haiku-os.org/haiku/tree/src/servers/media/NodeManager.cpp#n255

​http://cgit.haiku-os.org/haiku/tree/src/add-ons/media/media-add-ons/opensound/OpenSoundNode.cpp#n562

[umccullough]

Replying to bonefish:

Moreover coreutils and ctags fall into my 3rd party category.

FWIW, coreutils only seems to fail to link - and only on gcc2 at that, so perhaps this is something we should fix in our jamfiles instead... I don't even understand how DEBUG=1 affected this one based on my brief investigation.

[umccullough]

debug.c is required to compile ctags with DEBUG=1

[umccullough]

Allow ffmpeg sources to compile during debug build

[umccullough]

Allow libgutenprint sources to compile during debug build

[umccullough]

Fix debug build of libprint

[mmadia]

Replying to bonefish:

Regarding the patches:

Fix-implicit-void-cast-in-usb_midi-debug-code.patch
Fix-warning-in-AutoMounter-debug-code.patch
Fix-warning-in-BSnow-debug-code.patch
Fix-bad-debug-print-in-canna.patch
Fix-various-issues-in-cortex-debug-code.patch
Fix-PDF-print-driver-debug-code.patch
Fix-another-mouse-preference-issue-specific-to-gcc4-.patch

Signed-off-by: Ingo Weinhold <ingo_weinhold@gmx.de>

These seven have been applied in hrev43566

PS: It would really be nice to have that "Apply Patch" button in Trac.

Maybe that could be a GSoC project idea? I'm barely finding the time to make meager progress with our BuildBot setup.

[mmadia]

Fix-ASSERT-that-wasn-t-altered-back-in-hrev39770-all.patch applied in hrev43567

[umccullough]

Patch BuildSetup to disable DEBUG=1 support on subdirs with targets that won't compile as such

[mmadia]

applied Disabled-DEBUG-1-in-several-of-the-3rd-party-ffmpeg-.patch and Disable-DEBUG-build-of-3rd-party-libgutenprint.patch in hrev43601

[mmlr]

Similar patches applied in hrev43634 and hrev43635 applying/obsoleting Avoid-warning-in-debug-code-for-media-server.patch, Fix-warnings-in-OpenSound-debug-code.patch and Conditionally-add-debug.c-to-ctags-build.patch.

[mmlr]

Applied Remaining-subdirs-that-cannot-be-compiled-with-DEBUG.patch in hrev43638. Leaving this ticket open as at least some of the blacklisted items should be fixed. Alternatively a new ticket could be opened for that though.

[umccullough]

I think we can just close this one and open another ticket (or tickets) for the other issues.

The "buildsystem" changes are now in place, and the debug images are building with buildbot now at least - which was the goal of this ticket.

Thanks!