How can I generate the code for both x86 and x64 using MIDL?
I've created an IDL file in Visual Studio 2010, and when I compile the product as in x86 mode and afterwards in x64 I've got to "touch" the IDL file so it will regenerate the code relevant for x64. Can I somehow tell MIDL to generate both codes into the same file?
An IDL file defines an interface, that interface could use 64-bit platform features or 32-bit platform features. An IDL can be used to generate a stub; if an interface doesn't have 32-bit-platform-specific definitions or 64-bit-platform-specific definitions, supposedly on stub can be generated (i.e. one IDL file). But, that depends on the interfaces that you're exposing. Short answer: if you define you interfaces to be 32-bit and 64-bit compatible you shouldn't need two different IDL files--otherwise you need two different IDL files.
Without knowing what "touch" (which generally means updating the date/time of a file, w.r.t. software engineering) means, it's hard to say specifically what you need to do.
If you're referring to the files under the Generated Files folder, you won't see them change if all you change is the target platform (well, unless you've placed #ifdef blocks in the IDL that use platform-specific defines). Remember, the output of MIDL is source code, not binaries. The names of the datatypes used in the generated code won't change, so the output from MIDL will be the same even though the machine architecture the compiler is targeting is different.
You can verify this by making copies of the XXX_i.h and XXX_i.c files and comparing them between platforms. To do this, Build, make copies, Rebuild, then compare the files; the only thing that should be different is the timestamp.
So, to get back to your original question: you're already doing it!
I know this is an old question, but should anyone else hit this here is how I solved it.
In the project containing the IDL file, I added a pre-build event to all platforms and configurations that deleted the MIDL output files like this...
if exist $(ProjectName).h del $(ProjectName).h
if exist $(ProjectName)_i.c del $(ProjectName)_i.c
if exist $(ProjectName)_p.c del $(ProjectName)_p.c
I could have gotten away with just deleting the proxy (_p) file as that's the only platform specific MIDL generated file.
If your proxy stub source files have different names or extensions, use those.
Related
I have installed pycparser that parses C code.
Using pycparser I want to parse an open source project, namely PostgreSQL . However, during compilation it cannot found some header files, namely
pg_config_ext.h and pg_config_os.h.
While looking at the directory structure of PostgreSQL, I find that it does not have these header files. How to fix this issue?
These header files are generated from the respective .in files when configure is run.
This will allow conditional compilation depending on the operating system and its configuration.
To compile PostgreSQL, you need what is called a configured source tree in PostgreSQL jargon.
Also note that the build process is somewhat different on Windows, see the documentation for details.
I have heard that MEF reduces the need for creating config files, but if I have a few different plugin paths that vary depending on the client running the app, is it common and a good idea to have a config file that specifies the correct path. I want to avoid looping through all the DLLs.
Generally people have a well known plugin directory under the where the application is running from, i.e. \Extensions. However that said there isn't any particular reason you cannot do a configuration file for directories or exact extension assemblies.
I am tasked with setup a Mercurial version control system for our small team of developers (2-3 person). There was no version control system before, just shared folders and multi-copies. I don't have much experience in setting version control system except for personal projects, just happened to be the most experienced person in term of version control system in our team. The code repository is in a shared folder in centre server, the top leve directory is client name, one level down is project name for that client.
The problems is I haven't figure out how to deal with binary files in our code repository. From what I read, the binary files shouldn't be version tracked. But as the code repository is centralized on the server, shouldn't the binary in here as well? Otherwise for things like image file, and third-party dll files, the project wouldn't build or run properly when cloned from centre server. Also there is a nice feature for Mercurial web interface where you can download the whole source package as ZIP or BZ2 compressed file, without necessary binary files, the download project wouldn't run or compile.
I guess the solution is including everything for the version control system except the temporary files and the files for debug purpose, but other than that, most binary files should be included? Due to limitation of version control system, I don't think there is a way for them to track changes sets only for binary files, so I guess we have to deal with it for a version control system.
Edit: After more research about how to setup version-control repository, the more recommended way of using version-control is to "store everything which is created manually, and nothing else", quote from Eric Sink.
You want to version control anything that you can't generate from other stuff in version control. That would be your source files, and your instances of third-party libraries, tools, etc. that your package relies on.
The binaries built from your project are something else entirely, and should be treated as different sorts of artifacts. If you want an easy-to-test downloadable archive, adapt your build process to provide that as a target: it should build the code, and then compress the source and built binary into the desired single file.
Binary files that are related or required by the project must be included in version-control, they can be tracked. The only thing that version control can't do with binary files is compare and merge.
I'm interested in Qooxdoo as a possible web development framework. I have downloaded the SDK and installed it in a central location on my PC as I expect to use it on multiple projects. I used the create-application.py script to make a new test application and added all the generated files to my version control system.
I would like to be able to collaborate on this with other developers on other PCs. They are likely to have the SDK installed in a different location. The auto-generated files in Qooxdoo seem to include the SDK path in both config.json and generator.py: if the SDK path moves, the generator.py script stops working. generator.py doesn't seem to be too much of a problem as it looks in config.json for an updated path, but I'm not sure how best to handle config.json.
The only options I've thought of so far are:
Exclude it from the VCS, but there doesn't seem to be a script to regenerate it automatically, so this could be dangerous.
Add it to the VCS but have each developer modify the path line and accept that it might need to be adjusted whenever changes are merged.
Change config.json to be a path and a single 'include' line that points to a second file that contains all the non-SDK-path related information.
Use a relative path to the SDK and keep a separate, closely located copy of the SDK for every project that uses it.
Approach 1 would be ideal if the generation script existed; approach 2 is really nasty; I couldn't get approach 3 to work and approach 4 is a bit messy as it means multiple copies of the SDK littered about the place.
The Android SDK seems to deal with this very well (using approach 1), with the SDK path in its own file with a script that automatically generates that file. As far as I can tell, Qooxdoo puts lots of other important information in config.json and the only way to automatically generate that file is to create a new project.
Is there a better/recommended way to deal with this?
As an alternative to using symlinks, you can override the QOOXDOO_PATH macro on the command line:
./generate.py source -m QOOXDOO_PATH:<local_path_to_qooxdoo>
(Depending on the shell you are using you might have to apply some proper quoting of the -m argument). This way, every programmer can use his locally installed qooxdoo SDK. You can even drop the QOOXDOO_PATH entry from config.json to enforce this.
We work with a symbolic link pointing to the sdk ... config.json contains just the path of the link.
I'm trying to get glew to work under eclipse (mingw) in windows. Seems as if it is extremely unusual not to use Visual Studio in this context. The install instructions for glew is simply "use the project file in build/vc6/"...
The glew readme also writes:
"If you wish to build GLEW from scratch (update the extension data from
the net or add your own extension information), you need a Unix
environment (including wget, perl, and GNU make). The extension data
is regenerated from the top level source directory with:
make extensions"
In order to get glew to work in eclipse and windows I have to compile it in a unix environment? Is there no other way?
Sure, it would probably be a learning experience to pull that off (if I were to succeed) but I feel that my time is best spent actually working on my project. And even if I did manage to crosscompile everything, would it work in anything but Visual Studio?
Is the whole thing unfeasible and the best solution is to install Visual Studio?
Google haven't been of much help, I feel like I am the only one that has ever attempted to do this (is there a good reason this?).
Well if you still require some flexibility that the VS compiler doesn't always hold, you could try downloading the glew source zip file (on their main sourceforge page). Saying you have to have a Unix environment in order for it to work with eclipse is a huge mistake, as I have it working with MinGW at the moment. Just download the source, extract it, and create/put this batch file into the directory with "Makefile":
#echo on
set SYSTEM=mingw
set GLEW_DEST=C:\...[where you extracted it to]...\glew-1.7.0\usr
path = %PATH%;C:\MinGW\msys\1.0\bin;
make all
make install.all
pause
Change ...[where you extracted it to]... to the path you extracted the downloaded source zip to. Save that and run it, and you should see a "usr" folder containing all the dlls, libs, and headers you'll need. Copy those over to their respective OpenGL counterparts (or just anywhere where you'll be able to specify them in Eclipse later).
Now, in Eclipse, make a new project and at least be sure to include this somewhere:
#ifndef GLEW_STATIC
#define GLEW_STATIC
#endif //GLEW_STATIC
#include <Windows.h>
#include <GL/glew.h>
#include <GL/wglew.h>
If you put the glew headers somewhere besides the OpenGL headers, you may not have to use GL/. Now include the libraries by going into Project->Properties->C/C++ Build->Settings->Tool Settings->MinGW C++ Linker->Libraries and add the following libraries:
glew32
opengl32
glu32
glew32.dll
Add any library search paths you'll need. In my case I just used "C:\MinGW\lib" as a second measure.
Now save all your project files, use Project->Clean..., and build your project. If you don't get any glew errors and your project is prepared you should be able to run it.
Hope that works! It did for me.
Try the following:
Download the Windows 32-bit binary for GLEW here: http://glew.sourceforge.net/index.html
Follow the instruction to link your project to GLEW: http://glew.sourceforge.net/install.html
Make sure your Eclipse is also setup to compile with mingw. (I assume you've done this.)
cout << "Hello world!";