CAM.h should be in /boot/develop/headers/os/drivers/CAM.h as in BeOS

[schily]

CAM has no own hardware and is a pseudo driver.

cdrtools like to see the file on the same location as with BeOS

[nielx]

As I put in a comment on the mailing list, within the os headers, a header goes to device if it is used in userland, and to driver if it is used in kernel land. CAM.h is a bus_manager and as such used in kernel land, so the move would be a proper one.

Could you verify if any part of the build breaks when this file is moved from device to drivers?

[schily]

CAM.h is used in userland by libscg from cdrecord.

libscg/scsi-beos.c includes <drivers/CAM.h> If the file stays where it currently is, it breaks compiling cdrtools.

[axeld]

While Haiku is still a moving target (and thus these things could be changed), we do not necessarily provide 100% source compatibility, so if that header has been moved for a reason that's okay.

We also dropped BEOS as Haiku provides a much better POSIX experience, and ports should definitely be revisited in this regard.

Just as general information, I haven't really looked into the issue at hand :-)

[schily]

It would be nice is there was stability in the interfaces and I understand the include paths as part of the interfaces.

What was the reason to change the include path compared to BeOS 5 or Zeta?

[bonefish]

Replying to schily:

CAM.h is used in userland by libscg from cdrecord.

libscg/scsi-beos.c includes <drivers/CAM.h> If the file stays where it currently is, it breaks compiling cdrtools.

Including Be API headers with a directory part has been discouraged for ages. Just include <CAM.h> and it will work fine.

[schily]

When was the change to allow #include <CAM.h> introduced?

Was it with BeOS 5, Zeta or Haiku?

[axeld]

That already happened for BeOS, I just don't know if it was R5 or earlier.