Results 1 to 10 of 10

Thread: D3Dcompiler.h not found on Vista

  1. #1

    Default D3Dcompiler.h not found on Vista

    I'm building on Windows Vista. I have an old school Microsoft Windows 7.1 SDK and a separate DirectX SDK (June 2010). This arrangement predates the merger of the DXSDK into the Windows 8 SDK. The Windows 8 SDK is not supported on Vista, which is why I have the old arrangement. D3Dcompile.h is present in my DXSDK but ClanLib doesn't seem to be picking it up. I think it's picking up various D3D headers that are actually included in the 7.1 SDK, such as d3d11.h.

    You have a custom build system. I figure this is a configuration issue in there somewhere. Is there an easy fix? I'm building with VS10 so there's no global search path to add. I suppose I could add paths for individual projects, but I'm wondering how your build system should be handling this.

    Incidentally I'm building this to see how the OpenGL 3.x+ support is. I tried building on Linux but the build failed.

  2. #2
    ClanLib Developer
    Join Date
    May 2007
    Posts
    1,824

    Default

    What version of clanlib are you using?

    clanlib 2.3.6 for clanlib 2.3 SVN should compile on all platforms - linux and windows xp (or higher)

    clanlib 3.0 SVN should compile on windows platforms - Excluding clanD3D, since that requires the windows 8 sdk.

    You can delete clanD3D from the visual studio solution, if you don't need it.

    On Linux, it probably doesn't compile, because the makefiles haven't been updated in a while.
    clanlib 3.0 is still under development, it's usable, but half of the examples and tests are broken. Hopefully it'll be ready for release (i.e. stable API) sometime at the end of this year. This depends on the motivation of the developers

  3. #3

    Default

    3.0 SVN. I'll try deleting clanD3D. I don't see why Windows 8 SDK should be required to build a DX11 app. I realize you may not have put that configuration option in your build tool, and may not be very motivated to do anything about that case use, but DX11 doesn't require Windows 8 SDK. Thanks for heads up on your pace of 3.0 development, doesn't sound high priority.

  4. #4
    ClanLib Developer
    Join Date
    Sep 2006
    Location
    Denmark
    Posts
    554

    Default

    Quote Originally Posted by bvanevery View Post
    3.0 SVN. I'll try deleting clanD3D. I don't see why Windows 8 SDK should be required to build a DX11 app. I realize you may not have put that configuration option in your build tool, and may not be very motivated to do anything about that case use, but DX11 doesn't require Windows 8 SDK. Thanks for heads up on your pace of 3.0 development, doesn't sound high priority.
    Strictly speaking clanD3D does not require the Windows 8 SDK. If the include paths are correctly set up for the DirectX SDK it does compile and will work.

    Our project generator (configure.exe) generates normal Visual Studio projects with property sheets for its configuration. In other words it doesn't rely on any nmake or any other alternative build systems. It is not more than a few months ago I was building clanD3D myself with the June 2010 DirectX SDK, so my best guess really is that your include paths are simply not correct. To fix the include problem I suggest you either update the user property sheet, which will make it a global change in all your project, or create a new property sheet where the DirectX headers are specified.

    Note that the version of DirectX used during building of ClanLib determines which version of the D3DCompiler DLL is used. Since the Windows 8 SDK includes a newer version of the D3D compiler, and since there are some rather nasty bugs in the older version, I highly recommend that you use the Windows 8 SDK instead.

    I am fairly sure that the "requires Windows 7" thing of the Windows 8 SDK is Microsoft bullshit. If it really does refuse to install I'd personally install it on some Windows 7 machine, then copy the "C:\Program Files (x86)\Windows Kits\8.0" to my Vista machine, update the include paths and hit compile. I give it a 99% chance that it will work.

    Regarding the OpenGL support, the clanGL target supports 4.3 including compute shaders. This provided that the card and OpenGL driver supports it, of course.

    About the pace of 3.0 development, I think it is fairly high. It is just that we tend to never really get things released. Except for the out of date examples and Linux makefiles, I think 3.0 works well at the moment.

  5. #5

    Default

    Quote Originally Posted by Magnus Norddahl View Post
    Our project generator (configure.exe) generates normal Visual Studio projects with property sheets for its configuration. In other words it doesn't rely on any nmake or any other alternative build systems. It is not more than a few months ago I was building clanD3D myself with the June 2010 DirectX SDK, so my best guess really is that your include paths are simply not correct. To fix the include problem I suggest you either update the user property sheet, which will make it a global change in all your project, or create a new property sheet where the DirectX headers are specified.
    In a CMake or Autoconf style build system, there would be a querying phase that identifies where a given SDK is located, such as the DXSDK. Then the correct value would be placed in all the project files, rather than requiring the user to edit those entries by hand. This might be something to consider as a capability for your build system.

    Editing include directories manually didn't used to be any big deal in VS9, as there was a global setting for it. MS ditched that in VS10, and so projects with dozens of project files are rather much of a PITA to make the manual adjustments for each one. I don't know whether VS12 came up with a better way to do things. I'll look at that and also the Win8 SDK hack idea. I haven't been worrying about Windows for about a year now, was hoping to "end of life" that platform, but 3d engine debugging seems to drag me back into cross-platformdom.

  6. #6
    ClanLib Developer
    Join Date
    May 2007
    Posts
    1,824

    Default

    For others reading this and wondering how
    See - http://clanlib.org/wiki/VisualStudio2010GlobalIncludes

  7. #7

    Default

    Thanks for the global user directory info. I was able to use $(DXSDK_DIR) as a macro. Now I get piles of errors that seem to indicate a .h file incompatibility.
    8>c:\program files\microsoft directx sdk (june 2010)\include\d3d11shader.h(35): error C2146: syntax error : missing ';' before identifier 'D3D11_RESOURCE_RETURN_TYPE'
    I bet it has to do with newer vs. older versions of the DirectX .h files.

    Haven't tried hacking the Windows 8 SDK into Vista as I'm at a location with paltry bandwidth and haven't succeeded in downloading it yet. I'm not hopeful that it'll work. Doing a straight install from the internet does not work, as it blathers about not supporting Vista for most things and will only install a trivial number of utilities. I don't currently have a Windows 7 or 8 machine to install to first, then do a directory copy. So, either someone has figured out how to fool this thing and has instructions somewhere, or this is probably a no go.

  8. #8
    ClanLib Developer
    Join Date
    Sep 2006
    Location
    Denmark
    Posts
    554

    Default

    Quote Originally Posted by bvanevery View Post
    In a CMake or Autoconf style build system, there would be a querying phase that identifies where a given SDK is located, such as the DXSDK. Then the correct value would be placed in all the project files, rather than requiring the user to edit those entries by hand. This might be something to consider as a capability for your build system.
    In a CMake project the PDB files would not be correctly generated (that's *always* the case with every cmake project I encounter). Also, the projects generated would have all settings messed up together, the project name would often be ..\..\clanCore and you'd have to change any setting 8 times for each of the different target types (debug, release, 32 bit, 64 bit, etc). Or, you'd have to learn the CMake format itself and pray the setting you are looking for is reflected there.

    In a Autoconf build system you'd have to learn bash, m4, autoconf, automake, libtool and every macro intimately. The entire thing is IMO a hack that is only reasonable when explained in a historic context where GNU wanted their tools to compile on as many commercial Unixes as possible (back then SH was the only real common denominator, so their install script had to work with it). It is also not cross platform beyond Unixes (cygwin does not count), and their system would still not have a DXSDK setting unless we explicitly manually coded it (autoconf doesn't really do much for you).

    You are right of course that any extra features in our project generator would be nice. But compared to the current alternatives I think our home made generator still beats the alternatives. Maybe at some time CMake will improve, but for the time being I consider their Visual Studio project generator absolutely awful.

    Quote Originally Posted by bvanevery View Post
    Editing include directories manually didn't used to be any big deal in VS9, as there was a global setting for it. MS ditched that in VS10, and so projects with dozens of project files are rather much of a PITA to make the manual adjustments for each one. I don't know whether VS12 came up with a better way to do things. I'll look at that and also the Win8 SDK hack idea. I haven't been worrying about Windows for about a year now, was hoping to "end of life" that platform, but 3d engine debugging seems to drag me back into cross-platformdom.
    Since Visual C++ 2005 the build system supports something called property sheets. You can display them via the View->Property Manager in the menu. If you do this for the ClanLib solution, you will see all the different property sheets applied to each project and target. You are not meant to make manual adjustments on a project anymore. The system intends you to create a sheet for the specific change. Then you add that sheet to the project targets you want it to apply. Personally I rather like this system.

    Amongst these property sheets there's one called Microsoft.Cpp.Win32.user. This is where the new global includes are now located. If you add rules to this sheet they will apply to all projects on your system (with that user account).

    We haven't bothered to make a special "DirectX Path" property sheet simply because we personally just update the user global sheet one time for all. However, if you would like to have such a sheet, the steps are very simple: 1) select all projects in the Property Manager, 2) right-click and create a new sheet, 3) set the include and library paths in the sheet, 4) click OK and then build ClanLib.

    Thanks for the global user directory info. I was able to use $(DXSDK_DIR) as a macro. Now I get piles of errors that seem to indicate a .h file incompatibility.
    8>c:\program files\microsoft directx sdk (june 2010)\include\d3d11shader.h(35): error C2146: syntax error : missing ';' before identifier 'D3D11_RESOURCE_RETURN_TYPE'
    I bet it has to do with newer vs. older versions of the DirectX .h files.
    This may be caused by some bug in the earlier version of the header where some other D3D header has to be included first. Try add an include to <d3d11.h> above the <d3d11shader.h> include and see if that helps.

  9. #9

    Default

    Quote Originally Posted by Magnus Norddahl View Post
    In a CMake project the PDB files would not be correctly generated (that's *always* the case with every cmake project I encounter).
    I'd be surprised. Encountering bad builds "in the wild" is not the same thing as a build system lacking a capability. Have you tried the CMake mailing list or looked in their bug tracker on this issue? How recent a version of CMake have you encountered this behavior with?

    Also, the projects generated would have all settings messed up together, the project name would often be ..\..\clanCore and you'd have to change any setting 8 times for each of the different target types (debug, release, 32 bit, 64 bit, etc). Or, you'd have to learn the CMake format itself and pray the setting you are looking for is reflected there.
    The drill is to use and understand the CMake format, yes. Not much of a cross-platform accomplishment if you don't. CMake targets all of the major IDEs, and there's a price to pay somewhere for that.

    In a Autoconf build system you'd have to learn bash, m4, autoconf, automake, libtool and every macro intimately.
    Which is why, if you're interested in Visual Studio development, you don't. You learn CMake.

    You are right of course that any extra features in our project generator would be nice. But compared to the current alternatives I think our home made generator still beats the alternatives.
    I don't, because when I encountered a problem, I had to ask you what's going on, or dig into your special code "blind," instead of just fixing it myself as part of the standard CMake drill. Also your Linux build isn't working for me right now. If you had 1 build instead of 2 separate builds, that would be less likely. I don't think CMake is a *great* build system by any means, but it is the most accepted and industrially mature of the heavy duty cross-platform build tools now. I'm on Linux right now, but I've got a potential client that's Windows oriented. Ogre's CMake build system is more robust for keeping things in sync. Even Lua-based Premake might be better than you guys rolling your own, although I don't have any significant Premake experience. Premake lacks most of the FindSuchAndSuch capabilities that CMake has, but that said, the CMake FindSuchAndSuch capabilities are rusty / bad in certain areas, like OpenGL for instance.

    This may be caused by some bug in the earlier version of the header where some other D3D header has to be included first. Try add an include to <d3d11.h> above the <d3d11shader.h> include and see if that helps.
    Will try, thanks. BTW ClanLib 2.3.6 builds cleanly without any changes. The problem is in 3.0. EDIT: Ah! The problem is not 3.0 code. It's fine. The problem is that if you don't have DXSDK configured, then go back and configure it, the build is stale. Cleaning the build, then Rebuilding, fixes the problem. So, June 10 DXSDKers beware.
    Last edited by bvanevery; 03-13-2013 at 04:41 PM.

  10. #10
    ClanLib Developer
    Join Date
    Sep 2006
    Location
    Denmark
    Posts
    554

    Default

    Quote Originally Posted by bvanevery View Post
    I'd be surprised. Encountering bad builds "in the wild" is not the same thing as a build system lacking a capability. Have you tried the CMake mailing list or looked in their bug tracker on this issue? How recent a version of CMake have you encountered this behavior with?

    The drill is to use and understand the CMake format, yes. Not much of a cross-platform accomplishment if you don't. CMake targets all of the major IDEs, and there's a price to pay somewhere for that.

    Which is why, if you're interested in Visual Studio development, you don't. You learn CMake.
    Actually I'd argue that someone interested in Visual Studio development would primarily use the VC++ build system. As for how much you can tweak the output for Visual Studio with CMake, I do not know. All I can say is that the times I've used CMake I saw some rather nasty looking generated project files.

    In any case, my main point was more that no build system I know of simply offer something like "set the DirectX include path" out of the box. They may have a general one for extra includes, which our does have too, but this kind of customization would in all cases require you either learning their build system intimately, or you patch the generated files afterwards.

    Quote Originally Posted by bvanevery View Post
    I don't, because when I encountered a problem, I had to ask you what's going on, or dig into your special code "blind," instead of just fixing it myself as part of the standard CMake drill.
    I agree with your point that for other people it is easier to learn the CMake build system than our own generator. I just feel that until I have reasonable proof of some sort that CMake can indeed generate project files of acceptable quality, I personally favor having my custom generator that has worked for me for a very long time. I know I could spend a lot of time personally investigating CMake (for Windows), but to be honest the motivation for me just isn't there.

    Quote Originally Posted by bvanevery View Post
    Also your Linux build isn't working for me right now. If you had 1 build instead of 2 separate builds, that would be less likely. I don't think CMake is a *great* build system by any means, but it is the most accepted and industrially mature of the heavy duty cross-platform build tools now. I'm on Linux right now, but I've got a potential client that's Windows oriented. Ogre's CMake build system is more robust for keeping things in sync. Even Lua-based Premake might be better than you guys rolling your own, although I don't have any significant Premake experience. Premake lacks most of the FindSuchAndSuch capabilities that CMake has, but that said, the CMake FindSuchAndSuch capabilities are rusty / bad in certain areas, like OpenGL for instance.
    I'm actually all in favor of having the Linux version use CMake rather than Autoconf. Part of the reason the Linux build isn't working is because Autoconf is such a PITA and has no FindSuchAndSuch capabilities. It just happened to be the 'most accepted and industrially mature' build system for Linux in the past. The main problem in getting there is that someone would have to volunteer for the first big hurdle of creating the initial CMake config files.

    If it can also generate Windows project templates that would also be OK with me, although personally I'd only switch away from configure.exe until I think the generated projects match in quality.

    Quote Originally Posted by bvanevery View Post
    Will try, thanks. BTW ClanLib 2.3.6 builds cleanly without any changes. The problem is in 3.0. EDIT: Ah! The problem is not 3.0 code. It's fine. The problem is that if you don't have DXSDK configured, then go back and configure it, the build is stale. Cleaning the build, then Rebuilding, fixes the problem. So, June 10 DXSDKers beware.
    Dependency checking has never been Microsoft's strong side.

Similar Threads

  1. More Vista Problems
    By Pleng in forum Novashell Game Creation System
    Replies: 4
    Last Post: 07-17-2008, 06:54 AM
  2. vista bug and collision request
    By attle in forum Novashell Game Creation System
    Replies: 2
    Last Post: 06-19-2008, 03:27 AM
  3. Vista, ATI and ClanLIb (oh my)
    By madmark in forum Official ClanLib SDK Forums
    Replies: 6
    Last Post: 03-01-2008, 08:24 PM
  4. Won't compile under Vista
    By Scutter in forum Official ClanLib SDK Forums
    Replies: 1
    Last Post: 08-10-2007, 11:59 PM
  5. Novashell - Vista Compatible?
    By whisperstorm in forum Novashell Game Creation System
    Replies: 1
    Last Post: 02-01-2007, 12:41 PM

Bookmarks

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •