Opened 13 years ago
Closed 9 years ago
#556 closed defect (fixed)
MSVC x64 1.3.0 changes
| Reported by: | greg | Owned by: | Charlie Hull |
|---|---|---|---|
| Priority: | normal | Milestone: | 1.3.4 |
| Component: | MSVC makefiles | Version: | SVN trunk |
| Severity: | normal | Keywords: | |
| Cc: | Blocked By: | ||
| Blocking: | Operating System: | Microsoft Windows |
Description
MSVC files should be updated for 1.3.0. The attached patch file has the changes needed compile version 1.3.0 on windows x64 with visual studio 2010.
- Only the csharp bindings were updated the rest of the bindings should probably get a treatment as well.
- I removed the manifest generation lines since vs2010 had issues with generating those.
Attachments (1)
Change History (6)
by , 13 years ago
comment:1 by , 13 years ago
| Milestone: | → 1.3.0 |
|---|
Setting milestone.
Charlie said on IRC he'd try to review this next week.
comment:2 by , 13 years ago
| Milestone: | 1.3.0 → 1.3.x |
|---|---|
| Version: | → SVN trunk |
Paging Charlie...
(Bumping milestone to 1.3.x - this isn't a blocker for releasing 1.3.0, especially as Charlie can just update the makefiles after the release...)
comment:3 by , 13 years ago
Although I can review the patch, I don't have a 64-bit Windows box to test it on - so unfortunately I can't release makefiles. I'm hoping to have one in the New Year. If anyone can help do say...
comment:5 by , 9 years ago
| Milestone: | 1.4.x → 1.3.4 |
|---|---|
| Resolution: | → fixed |
| Status: | new → closed |
Charlie's no longer maintaining these makefiles. I don't use this compiler myself, but I've attempted to apply the changes, not helped by the rampant whitespace changes the patch includes.
Rather than commenting out all the uses of $(MANIFEST), I added a print and no-op version of $(MANIFEST) - untested I'm afraid.
The patch removed all the nmake [...] HEADERS commands, with no explanation as to why - AIUI, these are needed for the dependency generation to work, so I've added a way to disable these by setting a single variable (also untested).
Just adding the version suffix to XAPIAN_BINDINGS, etc seems a bad idea - it forces an update for every release, and also breaks building from a VCS checkout. Instead I've added a VERSION_SUFFIX variable which can be set so there's just one place to update (and guess what, untested).
Changing hard-coded paths to installed tools doesn't seem a useful change - it seems these are going to vary for almost everyone, so hard-coding them at all seems a really bad idea. Surely people must put them on their PATH in reality?
I'm unconvinced that these makefiles are a viable long term approach. They've always been a maintenance pain, due to duplicating much of the information encoded in the standard build system, and they've had no active maintainer for several years now. I'm pretty certain they don't work with current git master even after these updates, but that's best handled in a new ticket I think.
My preference would be that MSVC builds are supported via the standard build system. That will require a bit of work by a developer using MSVC, but so would getting these makefiles working again, and at least once the standard build system supports MSVC we'll be free of the tedious job of having to manually update lists of source files, binaries to build, etc here as well as in the standard build system.
That said, I'm OK with merging clean patches to these makefiles, but please don't mix whitespace changes and functional changes, as it makes it harder to see what the patch actually changes. I've done a mass whitespace cleanup, so if it was your editor messing with the whitespace, hopefully it won't now.
The aforementioned patch