Build Broken? Cannot compile under BeOS.

[bouncer]

Recently - when I attempt to compile Haiku on my BeOS environment, I am getting the following error ...

snip =======

AppendToHaikuImageCopyFilesScript <HaikuImage>haiku.image-copy-files-dummy-beos/system/add-ons/media/plugins C++ generated/objects/haiku/x86/release/add-ons/tracker/filetype/FileType.o Link generated/objects/haiku/x86/release/add-ons/tracker/filetype/FileType-F XRes1 generated/objects/haiku/x86/release/add-ons/tracker/filetype/FileType-F Chmod1 generated/objects/haiku/x86/release/add-ons/tracker/filetype/FileType-F SetType1 generated/objects/haiku/x86/release/add-ons/tracker/filetype/FileType-F MimeSet1 generated/objects/haiku/x86/release/add-ons/tracker/filetype/FileType-F mimeset: "generated/objects/haiku/x86/release/add-ons/tracker/filetype/FileType-F": No such file or directory

generated/objects/hrev5/x86/release/tools/mimeset -f "generated/objects/haiku/x86/release/add-ons/tracker/filetype/FileType-F" ;

...failed MimeSet1 generated/objects/haiku/x86/release/add-ons/tracker/filetype/FileType-F ... ...removing generated/objects/haiku/x86/release/add-ons/tracker/filetype/FileType-F ...skipped <HaikuImage>haiku.image-copy-files-dummy-beos/system/add-ons/Tracker for lack of FileType-F... ...skipped haiku.image for lack of <HaikuImage>haiku.image-copy-files... ...failed updating 1 target(s)... ...skipped 2 target(s)... ...updated 2217 target(s)... ========== eof ====================

I believe that I last performed a successfull compile at rev 21422. But, there is some doubt concerning the accuracy of my notes. I can guarantee that I was able to successfully compile the Haiku back at rev 21209.

[mmlr]

This happens since hrev21494. "update_mime_info" on line 52 in "./src/bin/mimeset.cpp" fails reproducably for the "FileType-F" add-on. If you change this line to not set the status the build works again. The actual problem comes from FileType-F and its rdef though. For some reason the app signature is commented in FileType.rdef. Therefore FileType-F misses a signature and mimeset fails.

[mmlr]

Should be fixed in hrev21496.

[bouncer]

Umm, no. Apparently, hrev21496 does not fix it.

clip ==

$ get_haiku.sh U /boot/home/haiku/src/add-ons/tracker/filetype/FileType.rdef Checked out revision 21496.

update complete.

clip ==

ResComp1 generated/objects/haiku/x86/common/add-ons/tracker/filetype/FileType.rsrc Link generated/objects/haiku/x86/release/add-ons/tracker/filetype/FileType-F XRes1 generated/objects/haiku/x86/release/add-ons/tracker/filetype/FileType-F Chmod1 generated/objects/haiku/x86/release/add-ons/tracker/filetype/FileType-F SetType1 generated/objects/haiku/x86/release/add-ons/tracker/filetype/FileType-F MimeSet1 generated/objects/haiku/x86/release/add-ons/tracker/filetype/FileType-F mimeset: "generated/objects/haiku/x86/release/add-ons/tracker/filetype/FileType-F": No such file or directory

generated/objects/hrev5/x86/release/tools/mimeset -f "generated/objects/haiku/x86/release/add-ons/tracker/filetype/FileType-F" ;

...failed MimeSet1 generated/objects/haiku/x86/release/add-ons/tracker/filetype/FileType-F ... ...removing generated/objects/haiku/x86/release/add-ons/tracker/filetype/FileType-F ...skipped <HaikuImage>haiku.image-copy-files-dummy-beos/system/add-ons/Tracker for lack of FileType-F... ...skipped haiku.image for lack of <HaikuImage>haiku.image-copy-files... ...failed updating 1 target(s)... ...skipped 2 target(s)... ...updated 694 target(s)...

[mmlr]

At least for me (BONE though) this change was enough to fix building the FileType-F add-on. But the problem occurs with other targets too so it is probably not really fixing the build.

Apparently the signature was commented out because the R5 equivalent has no signature either. It makes sense to that degree that FileType-F is not a standalone application and therefore doesn't really need an app sig.

Maybe a failing "update_mime_info" should just be non-fatal like the "create_app_meta_mime" a few lines below.

Reopening the ticket as we probably should modify mimeset.

[mmlr]

I have further tested and tracked this down. My results are as follows:

The resource file is correctly compiled (FileType.rsrc) by rc. The resources are correctly transferred to the binary (FileType-F) by xres. The description and version info are intact here. This is the point where mimeset is called and where update_mime_info() fails on BeOS hosts. The version info is not affected by this though. Then setversion is used to set the system version info. To work around bug #681 it tries to see if there is an invalid version info set that needs to be cleared out. It does that by using GetVersionInfo() of BAppFileInfo. BAppFileInfo does not handle files that have no app signature set (as they are supposed to be no application) and therefore fails the GetVersionInfo() call. The version info that was set by xres is cleared out and the resulting binary has no description / version info set.

So this seems to boil down to a BeOS "bug". I'd not actually call it a bug as it makes sense to say that an app that has no app signature is invalid.

Anyway, mimeset has nothing to do with the missing information and should simply not fail when update_mime_info() fails as this seems completely non fatal. Therefore I changed this in hrev21518 and this should get the BeOS build going again.