You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Robert Greig <ro...@gmail.com> on 2008/11/26 23:52:18 UTC

Windows Build

Hi Steve,

I've been taking a look at the Windows build, since I'm keen to use
qpid C++ on that platform.

I noticed that on trunk the VS project is slightly out of date with
the generated files so it doesn't build (looks like a couple of
generated events had either been renamed or removed?).

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.

Are you making any changes to the VS project just now? I'd like to
commit these but I don't want to disrupt anything you're doing.

Robert

Re: Windows Build

Posted by Robert Greig <ro...@gmail.com>.
2008/11/30 Robert Greig <ro...@gmail.com>:

> 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?

Sorry, I see that the cpp tarball is what we're expecting people to
download and does contain all the generated files. I had previously
assumed that it was a build of the C++ broker (for linux).

RG

Re: Windows Build

Posted by Robert Greig <ro...@gmail.com>.
2008/11/28 Steve Huston <sh...@riverace.com>:

>> 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

RE: Windows Build

Posted by Steve Huston <sh...@riverace.com>.
Hi Robert,

> Hi Steve,
> 
> I've been taking a look at the Windows build, since I'm keen to use
> qpid C++ on that platform.

Great!

> I noticed that on trunk the VS project is slightly out of date with
> the generated files so it doesn't build (looks like a couple of
> generated events had either been renamed or removed?).

Hmmm... That happens.

> 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.

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.

> Are you making any changes to the VS project just now? I'd like to
> commit these but I don't want to disrupt anything you're doing.

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.

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.

-Steve