2008/11/28 Steve Huston <[EMAIL PROTECTED]>: >> Obviously that was simple to fix, and I've also added a custom build >> step (and the spec file) to the project so that a user doesn't have > to >> run nmake separately from the command line. > > I originally did this, but removed it during the git-to-svn merge. My > thoughts were that since the Qpid release process generates the files, > "normal" users won't need to generate them and may not have the > ruby/python needed to do it. It's only needed by qpid developers > working from svn, so I moved the generate to a separate procedure. I > have a Windows-specific install document written as well.
I just looked at the tar.gz produced by Rafi for the M4 beta (http://people.apache.org/~rhs/qpid-incubating-M4-beta/qpid-incubating-M4-beta.tar.gz) and it did not contain the generated files? > Also, even if the generated code is done, there's no way that I've > found to bring any new files into the project file. Yes, this is a real pain. It would be nice if VS had an option to add a directory tree to a project that reflected the current state of the directory on disk at any point in time. > I have some things, yes. Additionally, I've been generating the > sln/vcproj files (and that does find all the generated code) so if you > check it in, it'll likely show up as much more changed than just what > you added. Aha - I agree that generating the project files is the best solution. > It is not a perfect scheme, and I'm open to suggestion for > improvements, but adding the generating step is, I think, worse for > non-developers. Let me know what you think. I agree that getting users to download both ruby and python just to do the generation process will be a pain for them (incidentally I don't know why we need to have two languages involved in code generation...). If we can get source releases to include the generated files then I agree that your approach is the right one. RG
