[haiku-commits] Re: r40858 - in haiku/trunk: headers/build/os/storage headers/os/storage src/build/libbe/storage src/build/libbe/storage/mime src/kits/storage ...

  • From: Ingo Weinhold <ingo_weinhold@xxxxxx>
  • To: haiku-commits@xxxxxxxxxxxxx
  • Date: Wed, 09 Mar 2011 11:50:31 +0100

On 2011-03-08 at 19:22:22 [+0100], Jonas Sundström <jonas@xxxxxxxxxxx> wrote:
> Jonas Sundström <jonas@xxxxxxxxxxx> wrote:
> > Ingo Weinhold <ingo_weinhold@xxxxxx> wrote:
>  ...
> > /Source/haiku/haiku/src/build/libbe/storage/mime/UpdateMimeInfoThread.cpp:
> > 277:
> >  no matching function for call to `BAppFileInfo::GetCatalogEntry 
> >  (char[720])'
>  ...
> > gcc -c "src/build/libbe/storage/mime/UpdateMimeInfoThread.cpp" -O2 -Wall
> >  -Wno-trigraphs -Wno-ctor-dtor-privacy -Woverloaded-virtual 
> >  -Wpointer-arith
> >  -Wcast-align -Wsign-compare -Wno-multichar
> >  -include headers/build/HaikuBuildCompatibility.h 
> >  -D_ZETA_USING_DEPRECATED_API_=1
> >  -D_ZETA_TS_FIND_DIR_=1 -DARCH_x86 -D_NO_INLINE_ASM -DCOMPILE_FOR_R5
> >  -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -DHAIKU_HOST_PLATFORM_HAIKU
> >  -Ibuild/user_config_headers -Ibuild/config_headers -Isrc/tools
> >  -Igenerated/objects/common/tools 
> >  -Igenerated/objects/haiku_host/x86/common/tools
> >  -Igenerated/objects/haiku/x86/common/tools -Isrc/bin -I-
> >  -Iheaders/build/private/app -Iheaders/build/private/storage
> >  -Iheaders/build/host/haiku_host
> >  -o 
> >  "generated/objects/haiku_host/x86/release/tools/UpdateMimeInfoThread.o" ;
>  ...
> > ...skipped <build>mimeset for lack of <src!tools>UpdateMimeInfoThread.o...
>  ...
> > one would think the header gets included from somewhere
> 
> Rene helped me see that the host platform's (Haiku's)
> /boot/develop/headers/os/storage/AppFileInfo.h
> is the one that gets included here.
> 
> I tried commenting out the "USES_BE_API" in the five Jamfiles
> of src/build/libbe  <libbe_build>
> but AppFileInfo.h still gets included from /boot/develop/headers.
> 
> Anyone familiar with the build system got any clues for me here?

I believe the problem occurs only on BeOS/Haiku compatible host platforms. 
Under Linux, FreeBSD, etc. it should work as you intended it to. The root 
problem is that under Haiku we don't build a libbe_build, but use the host 
system's libbe instead (and also the corresponding headers as you have 
noticed). This should be fixed, but so far I haven't found the motivation to 
do so.

If you look at how <build>mimeset is built, you'll already see work-arounds 
for essentially the same problem. E.g. Mime.cpp is built directly into 
<build>mimeset. You need to do the same with AppFileInfo.cpp. Moreover you 
need to make sure the files that require the build version of AppFileInfo.h 
header include it. The changes would look like this (untested):

        local mimesetSources =
                mimeset.cpp
                ...
        ;

        if $(HOST_PLATFORM) = haiku_host {
                mimesetSources += AppFileInfo.cpp ;
        }

        BuildPlatformMain <build>mimeset :
                $(mimesetSources)
                ...
        ;

        ...

        if $(HOST_PLATFORM_BEOS_COMPATIBLE) {
                SEARCH on [ FGristFiles AppFileInfo.cpp ]
                        = [ FDirName $(HAIKU_TOP) src build libbe storage ] ;

                SourceSysHdrs AppFileInfo.cpp UpdateMimeInfoThread.cpp
                        : [ FDirName  $(HAIKU_TOP) headers build os storage ] ;
        }

I hope that setting the header directory on the respective sources works as 
expected, i.e. it actually precedes the host system headers and doesn't cause 
any other damage either. Otherwise one might need to force-include the 
respective header.

CU, Ingo

Other related posts: