bmake error - missing dependency

Hi Mark Gao,

From what you provided, your issue would appear to be very similar to this recent post where your MicroStation SDK was installed to a Drive not fully Microsoft 8DOT3NAME compliant.  The quickest path to resolve is to either: a.) Verify and Confirm Microsoft 8DOT3NAME compliance for the MicroStation product and MicroStation SDKs (both required), or b.) Install the MicroStation product and/or MicroStation SDK in paths that do not contain spaces.  Following the advice in the link above can help you towards ensuring option a can be achieved.

HTH,
Bob

Hi Mark Gao,

From what you provided, your issue would appear to be very similar to this recent post where your MicroStation SDK was installed to a Drive not fully Microsoft 8DOT3NAME compliant.  The quickest path to resolve is to either: a.) Verify and Confirm Microsoft 8DOT3NAME compliance for the MicroStation product and MicroStation SDKs (both required), or b.) Install the MicroStation product and/or MicroStation SDK in paths that do not contain spaces.  Following the advice in the link above can help you towards ensuring option a can be achieved.

HTH,
Bob

Thanks Bob, it does the trick!

Robert Hook said:

Install the MicroStation product and/or MicroStation SDK in paths that do not contain spaces

Is that a reasonable suggestion for a product that is advertised as Windows-compliant, where the usual folder for 64-bit application installation is C:\Program Files?

This issue of files and folders that contain a space has been around for decades, or at least since Microsoft introduced long file names to Windows NT.  The problem lies with the development tools, starting with bmake. 

Why can't bmake and other Bentley tools perform the equivalent of 8DOT3NAME compliance internally? 

Hi Jon Summers,

Windows paths and being Windows compliant behavior (afaik and believe it or not ) should be in compliance by: a.) offering a default location for the application (bitness considered) like "Program Files", and b.) installer permitting users to provide an alternate path (spaces or not).

For the MSCE SDK to become fully space compatible requires several stages that I have been trying to move along as time/resources permit:

1. Developer Shell Space Compliance. In MSCE U16 SDK I did a fair amount of updates to help ensure the Developer Shell Environment (batch/scripts) should be mostly if not fully space compliant. Ref: SDK-8DOT3NAME
2. SDK Tools Space Compliance. I have done some early validation/testing (unfortunately prior to above so need to revisit) to determine what tools are not space compliant. I believe Rcomp.exe is one of those tools having issues and will file Bugs as soon as I am able to for each tool
3. SDK Delivered Make File Compliance. This is/was one of the primary issues that held back most efforts/needs to move progress w/spaces ahead on our tools. Granted our make tools and files are not directly bound to GNU make (though very similar in syntax); GNU make now supports spaces addressing the original bug filed in 2002 (and finally fixed in March 2021) it made sense to me and why I started doing some work on this topic to move our environment and tools forward.
4. User Make File Compliance. In an ideal world changes made above can/should be as transparent as possible wrt prior (MSCE SDK based) code and all: Tools and MKE/MKI files detect explicit use of quotes to handle spaces properly and 8DOT3NAME compliance otherwise. Doing so would permit users to "Opt-in" and "Upgrade" their own project make files at their own need and convenience.  I will try to make sure we proceed in this direction, but there may be a need to modify all user existing make file projects if we are unable to meet these conditions. I will do everything possible to ensure we make compatible and transparent changes as much as possible.

So to this point #1 should be complete. #2, #3 and #4 will continue to make some steady progress given the many moving/evolving parts: internal/external needs, updates/progress being made directly to the SDK; being consumed by 12 other Bentley product SDKs and still in our SDK Roadmap; wanting to fully explore and move many parts towards an online GitHub repository project.

Lastly, I am modifying my workflows to be able to more directly make changes more quickly in our processes and hope to see some of these backlog items move along more quickly going forward.

HTH,
Bob