Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[salithus]

http://1drv.ms/1wqBhDR - salithus_dfhack-0.40.13-r0-Windows.zip

Here's the steps I'm using:

Spoiler: compile on Windows (click to show/hide)

You need:
CMake
Git - I prefer Github or mysysgit for these purposes (simple command line stuff).
Perl - Strawberry Perl is simplest
Visual Studio 2010 Express for C#

• Install all four of the above programs.
• Hold down Shift and right-click in an empty space on your desktop. Select "Open command window here".
• Type "git clone git://github.com/dfhack/dfhack.git" and hit Enter.
• Type "cd dfhack" and hit Enter.
• Type "git submodule init" and hit Enter.
• Type "git submodule update" and hit Enter.
• Type "cd library" and hit Enter.
• Type "cd xml" and hit Enter.
• Type "git fetch origin" and hit Enter.
• Type "git checkout origin/master" and hit Enter.
• Close the command prompt and open the DFHack folder you just made
• Open up CMakeLists.txt
• Change line 61 from set(DF_VERSION "0.40.12") to set(DF_VERSION "0.40.13")
• Change line 61 from SET(DFHACK_RELEASE "r1" CACHE STRING "Current release revision.") to SET(DFHACK_RELEASE "r0" CACHE STRING "Current release revision.")
• Open the Build folder inside of the DFHack folder you made.
• Double-click on 'generate-MSVC-gui.bat'.
• In the window that pops up, uncheck the box that says "DL_RUBY", then click Configure, and lastly click Generate.
• Close that window and enter the new VC2010 directory that was created and double-click on dfhack.sln.
• Open the "Solution Explorer" tab to the right, scroll down to "PACKAGE", and then right-click on it and hit "Build".
• When it eventually finishes running, open the new folder "_CPack_Packages", then the folder "win32", then the folder "ZIP", and you will have your very own zipped-up DFHack build.

Sources:
http://www.bay12forums.com/smf/index.php?topic=139553.msg5614774#msg5614774
http://www.bay12forums.com/smf/index.php?topic=139553.msg5655714#msg5655714
http://www.bay12forums.com/smf/index.php?topic=138754.msg5655860#msg5655860
http://www.bay12forums.com/smf/index.php?topic=139553.msg5659030#msg5659030

e: corrected which repo I used (master, not develop)

[0x517A5D]

[...] This brings up another point: there are now multiple "0.40.12-r1" builds floating around that have different behaviors and features. Among other things, "hack-wish" no longer crashes in certain cases, "search" has been updated for 0.40.12, and workflow no longer produces repeating error messages. However, since builds built before these changes identify themselves as "0.40.12-r1", there's no easy way to tell which build of "0.40.12-r1" that specific bug reports apply to, for example.

That.  That's been a persistent problem for the past month, month and a half.

Not only is it causing confusion, it's also against the DFHack license.

[...]
2. Altered source versions must be plainly marked as such, and
must not be misrepresented as being the original software.
[...]

Now in the current mess, salithus didn't exactly alter the source; he mixed-and-matched code from the official repo, part of it at a time when the repo was between official releases.  As I understand it.

It's still a problem.

Maybe the actual repo master branch should always have a DFHACK_RELEASE string with "-unofficial" appended to it?  (EDIT: in the file CMakeLists.txt)

And to make an official release, branch the master and change only that one string?

How about it, Peterix, expwnent, lethosor ?

[salithus]

Maybe the actual repo master branch should always have a DFHACK_RELEASE string with "-unofficial" appended to it?

And to make an official release, branch the master and change only that one string?

How about it, Peterix, expwnent, lethosor ?

To clarify in case it matters:

* When I did the .12 release, I used the develop branch because I was just copypasta-ing instructions.
* When I did the .13 release (just now) I used the master branch to make sure I didn't pull anything that wasn't released yet.

[Octopusfluff]

Also, can we please quit approaching this with the "it won't fix this every time" mentality? I know that there are going to be times between versions that compatibility will break. My point is that it is not every release as evidenced by being able to use .40.11-r1 source with .40.12 symbols, so there is clearly an opportunity to improve the process.

The intensity with which you are approaching this almost suggests you see some kind of moral or ethical failing, which I find curious.

An important element to remember for working on a project like this is there's more than just the "can we do it" question. Yes, it's possible to /sometimes/ provide the capability to transition from one version to the next without source alteration. The next question is, "how often can we do it?"

We don't know. Toady provides the complete absence of any kind of guarantee as to when there will be changes that require more than a new symbol table. It might be major releases. It might be minor releases. It might be every time he updates a typo.

Consequently, there's absolutely no way to set useful expectations for actual end users. This is not a problem to be dismissed lightly; providing a mechanism will to most users imply a promise, and if that promise is not kept, people react in silly ways. From a social standpoint, it's often easier to not imply that promise.

As Peterix noted, if you want to try to improve things in the way you feel they should be improved, there's no real barrier to doing so, beyond you needing to choose to be responsible for it.

[Putnam]

Toady's gone a bit farther than that; he provides the guarantee of a complete absence of guarantee. He's said before that he doesn't want to have to keep 3rd party programs in mind when he writes Dwarf Fortress; it's pretty much the same problem as a UI API.

[salithus]

Also, can we please quit approaching this with the "it won't fix this every time" mentality? I know that there are going to be times between versions that compatibility will break. My point is that it is not every release as evidenced by being able to use .40.11-r1 source with .40.12 symbols, so there is clearly an opportunity to improve the process.

The intensity with which you are approaching this almost suggests you see some kind of moral or ethical failing, which I find curious.

I find it absurd that lethosor keeps insisting that since we can't guarantee non-breaking changes every time a new DF is released, we can't improve the DFHack versioning approach. If you find that curious...ok?

Consequently, there's absolutely no way to set useful expectations for actual end users. This is not a problem to be dismissed lightly; providing a mechanism will to most users imply a promise, and if that promise is not kept, people react in silly ways. From a social standpoint, it's often easier to not imply that promise.

That's a poor argument for not trying to improve the release cycle, especially considering the attitude prior to this discussion was largely "well if the DFHack team isn't going fast enough for you, build it yourself". Which I did. Which caused this discussion.

As Peterix noted, if you want to try to improve things in the way you feel they should be improved, there's no real barrier to doing so, beyond you needing to choose to be responsible for it.

That's disingenuous. There is a very real barrier to changing, fundamentally, how DFHack versioning works. It's got to be accepted by both the core DFHack team and the people developing plugins as both an improvement to the existing system and easier to use. No point in me wasting time writing anything in code if the current viewpoint of the DFHack team doesn't change to accept both the possibility and necessity of making this kind of improvement.

[Octopusfluff]

The intensity with which you are approaching this almost suggests you see some kind of moral or ethical failing, which I find curious.

I find it absurd that lethosor keeps insisting that since we can't guarantee non-breaking changes every time a new DF is released, we can't improve the DFHack versioning approach. If you find that curious...ok?

You act as though some moral wrong has been perpetrated. The dfhack team has opted not to take responsibility for a thing they CANNOT take responsibility for, and for you it's some kind of crime against release policies or something. That's what I find curious.

Consequently, there's absolutely no way to set useful expectations for actual end users. This is not a problem to be dismissed lightly; providing a mechanism will to most users imply a promise, and if that promise is not kept, people react in silly ways. From a social standpoint, it's often easier to not imply that promise.

That's a poor argument for not trying to improve the release cycle, especially considering the attitude prior to this discussion was largely "well if the DFHack team isn't going fast enough for you, build it yourself". Which I did. Which caused this discussion.

You built it yourself, you got what you wanted, and you have a viable pattern for doing so again in the future, so as far as I can tell, your actual technical problem has been solved, and now you're attacking a social problem. This leads to...

As Peterix noted, if you want to try to improve things in the way you feel they should be improved, there's no real barrier to doing so, beyond you needing to choose to be responsible for it.

That's disingenuous. There is a very real barrier to changing, fundamentally, how DFHack versioning works. It's got to be accepted by both the core DFHack team and the people developing plugins as both an improvement to the existing system and easier to use. No point in me wasting time writing anything in code if the current viewpoint of the DFHack team doesn't change to accept both the possibility and necessity of making this kind of improvement.

Disingenuous? How? The team, at present, doesn't consider the benefits worth the effort, but is open to contributions. You've provided steps for solving the problem locally. If you want the problem solved on a larger scope, then put in the legwork to solve it on a larger scope. If it's good work, and it does what you think it will do, it's likely to get merged.

[salithus]

You act as though some moral wrong has been perpetrated. The dfhack team has opted not to take responsibility for a thing they CANNOT take responsibility for, and for you it's some kind of crime against release policies or something. That's what I find curious.

That is not an accurate description of what has happened and you know that. You sound sillier each time you try and act like this is a morality crusade, though, which is amusing at least, so keep it up I guess?

You built it yourself, you got what you wanted, and you have a viable pattern for doing so again in the future, so as far as I can tell, your actual technical problem has been solved, and now you're attacking a social problem. This leads to...

No I have not - Starter Pack still depends on an official DFHack release only because that's what it currently takes to get a release that is considered stable and works with the latest DF version. There is, based on the discussions so far, an opportunity to change that since both 11->12 and 12->13 only required a symbols.xml update, but due to the way DFHack is currently maintained this requires everything to be recompiled by the DFHack team to make the versions aligned and it to be considered stable, which is what is required for inclusion in the Starter Pack. What I want is to separate DF versioning from DFHack versioning from plugin versioning so that when DF makes non-breaking changes in an upgrade, the's no need for an unsupported "at your own risk" build in order to update.

Disingenuous? How? The team, at present, doesn't consider the benefits worth the effort, but is open to contributions. You've provided steps for solving the problem locally. If you want the problem solved on a larger scope, then put in the legwork to solve it on a larger scope. If it's good work, and it does what you think it will do, it's likely to get merged.

I described it already, but given your other posts it's not surprising that you'll ignore both that and the implications of a core change like this, given your above approach to replying to me. This isn't creating a new plugin - it would require DFHack and all the plugins to be updated to use a new system - that's not something that just gets done off on a branch and suddenly everyone becomes accepting of it.

[IRIS_EYE_AZURE]

[...] This brings up another point: there are now multiple "0.40.12-r1" builds floating around that have different behaviors and features. Among other things, "hack-wish" no longer crashes in certain cases, "search" has been updated for 0.40.12, and workflow no longer produces repeating error messages. However, since builds built before these changes identify themselves as "0.40.12-r1", there's no easy way to tell which build of "0.40.12-r1" that specific bug reports apply to, for example.

That.  That's been a persistent problem for the past month, month and a half.

Not only is it causing confusion, it's also against the DFHack license.

[...]
2. Altered source versions must be plainly marked as such, and
must not be misrepresented as being the original software.
[...]

Now in the current mess, salithus didn't exactly alter the source; he mixed-and-matched code from the official repo, part of it at a time when the repo was between official releases.  As I understand it.

It's still a problem.

Maybe the actual repo master branch should always have a DFHACK_RELEASE string with "-unofficial" appended to it?  (EDIT: in the file CMakeLists.txt)

And to make an official release, branch the master and change only that one string?

How about it, Peterix, expwnent, lethosor ?

I'd rather the DFHack developers not worry about unofficial builds. And I think those willing to build DFHack on their own should be hesitant to provide those builds to others -- do we really want to encourage others to download and run unknown executable's? 

But I can see the need to provide bleeding edge builds for lazy eager die-hards who want to run Toady's latest and have their DFHack too. Here's my solution: If someone wants to post a link or reference to an unofficial build, just do so in a separate message thread. Anyone wanting the official build can come here (or the latest thread), which is identified by the current version.

For those working on starter and mod packs, put whatever *you* want in those packs; just understand that users expect some level of testing on your part to identify any major issues or problems (and aren't likely to care at all about version identifiers).

[salithus]

[...] This brings up another point: there are now multiple "0.40.12-r1" builds floating around that have different behaviors and features. Among other things, "hack-wish" no longer crashes in certain cases, "search" has been updated for 0.40.12, and workflow no longer produces repeating error messages. However, since builds built before these changes identify themselves as "0.40.12-r1", there's no easy way to tell which build of "0.40.12-r1" that specific bug reports apply to, for example.

That.  That's been a persistent problem for the past month, month and a half.

Not only is it causing confusion, it's also against the DFHack license.

[...]
2. Altered source versions must be plainly marked as such, and
must not be misrepresented as being the original software.
[...]

Now in the current mess, salithus didn't exactly alter the source; he mixed-and-matched code from the official repo, part of it at a time when the repo was between official releases.  As I understand it.

It's still a problem.

Maybe the actual repo master branch should always have a DFHACK_RELEASE string with "-unofficial" appended to it?  (EDIT: in the file CMakeLists.txt)

And to make an official release, branch the master and change only that one string?

How about it, Peterix, expwnent, lethosor ?

I'd rather the DFHack developers not worry about unofficial builds. And I think those willing to build DFHack on their own should be hesitant to provide those builds to others -- do we really want to encourage others to download and run unknown executable's? 

But I can see the need to provide bleeding edge builds for lazy eager die-hards who want to run Toady's latest and have their DFHack too. Here's my solution: If someone wants to post a link or reference to an unofficial build, just do so in a separate message thread. Anyone wanting the official build can come here (or the latest thread), which is identified by the current version.

For those working on starter and mod packs, put whatever *you* want in those packs; just understand that users expect some level of testing on your part to identify any major issues or problems (and aren't likely to care at all about version identifiers).

Eh, 0x517A5D's suggestion makes sense for the current process at least - if you were to download and build a bleeding edge release now, it'd have the same DFHack version as the latest stable release. That's what causes the DFHack devs to have to worry about unofficial builds in the first place.

[lethosor]

No I have not - Starter Pack still depends on an official DFHack release only because that's what it currently takes to get a release that is considered stable and works with the latest DF version. There is, based on the discussions so far, an opportunity to change that since both 11->12 and 12->13 only required a symbols.xml update, but due to the way DFHack is currently maintained this requires everything to be recompiled by the DFHack team to make the versions aligned and it to be considered stable, which is what is required for inclusion in the Starter Pack. What I want is to separate DF versioning from DFHack versioning from plugin versioning so that when DF makes non-breaking changes in an upgrade, the's no need for an unsupported "at your own risk" build in order to update.

DF 0.40.13 does require structure changes, due to this commit.
Anyway, I'm not opposed to changes in DFHack's versioning system; I'm just not sure how best to implement them. There was a discussion about this earlier on IRC where replacing the DFHack version string with a reference to a Git commit was brought up:

Code: [Select]

$ git describe --tags --always
0.34.11-r5-338-g856a146
Unfortunately, defining this as a constant will require rebuilding everything DFHack-specific (DFHack core and plugins) after every commit, which is impractical. Using a reference to a df-structures commit instead will require rebuilding less often, but is still more inconvenient than the current method, which only rebuilds plugins (and core modules) that use structures that have changed since the last build. The problem, of course, is that there is no easy way to tell which df-structures commit a compiled plugin was built with without introducing some kind of unique identifier, and I'm not aware of a way to do this without causing CMake to unnecessarily rebuild all plugins.

Maybe the actual repo master branch should always have a DFHACK_RELEASE string with "-unofficial" appended to it?  (EDIT: in the file CMakeLists.txt)

And to make an official release, branch the master and change only that one string?

Expwnent mentioned doing this after making a release, although it doesn't appear to have been changed yet. Generally, the master branch points to the latest release, but it would be easy to change the version string on the develop branch after making a release.

[Octopusfluff]

No I have not - Starter Pack still depends on an official DFHack release only because that's what it currently takes to get a release that is considered stable and works with the latest DF version. There is, based on the discussions so far, an opportunity to change that since both 11->12 and 12->13 only required a symbols.xml update, but due to the way DFHack is currently maintained this requires everything to be recompiled by the DFHack team to make the versions aligned and it to be considered stable, which is what is required for inclusion in the Starter Pack. What I want is to separate DF versioning from DFHack versioning from plugin versioning so that when DF makes non-breaking changes in an upgrade, the's no need for an unsupported "at your own risk" build in order to update.

There is an opportunity, yes. There is also an opportunity cost, which the team is not comfortable with at this time. That might change, particularly with a demonstration of implementation.

I described it already, but given your other posts it's not surprising that you'll ignore both that and the implications of a core change like this, given your above approach to replying to me. This isn't creating a new plugin - it would require DFHack and all the plugins to be updated to use a new system - that's not something that just gets done off on a branch and suddenly everyone becomes accepting of it.

I'm ignoring nothing. The implications of a change like that are significant, and someone has to actually do the work. A description is not sufficient. You're demanding someone else do it for you. This is not how to win friends and influence enemies.

[salithus]

DF 0.40.13 does require structure changes, due to this commit.

So, if I understand things right, that means the build I made above did processing of the structures during compile time that, if I included that commit (I think I did based on your instructions for the /library/xml folder), it "safely" updated all the DFHack-included plugins, but, despite being the same original source (master branch of DFHack), previous DLLs would not work (aside from the version string issue), due to those changes?

I really am trying to understand the process and how things currently work, despite any appearances to the contrary.

Anyway, I'm not opposed to changes in DFHack's versioning system; I'm just not sure how best to implement them. There was a discussion about this earlier on IRC where replacing the DFHack version string with a reference to a Git commit was brought up:

Code: [Select]

$ git describe --tags --always
0.34.11-r5-338-g856a146
Unfortunately, defining this as a constant will require rebuilding everything DFHack-specific (DFHack core and plugins) after every commit, which is impractical. Using a reference to a df-structures commit instead will require rebuilding less often, but is still more inconvenient than the current method, which only rebuilds plugins (and core modules) that use structures that have changed since the last build.

That makes sense - let me think on it. If I were doing this with SVN, I'd just reference an svn:externals and do some pre-build scripting based on that, but I'm not sure how that concept works in git. I can google my way around it, but any pointers on how you guys are doing it would be appreciated.

Maybe the actual repo master branch should always have a DFHACK_RELEASE string with "-unofficial" appended to it?  (EDIT: in the file CMakeLists.txt)

And to make an official release, branch the master and change only that one string?

Expwnent mentioned doing this after making a release, although it doesn't appear to have been changed yet. Generally, the master branch points to the latest release, but it would be easy to change the version string on the develop branch after making a release.

It really comes down to how you want people who are compiling themselves to do it. When I did it with .40.12, I just followed the step by step instructions because it was my first time. With .40.13, I did the master branch thinking it'd prove more of a point about how close the DF code was across the 3 releases and I didn't want to unknowingly include active development that might address an issue I wasn't aware of. Whichever I should be compiling against, that's the one I recommend not have an official version string as the default. (Might even be worth taking those lines out of source control entirely somehow [addmittedly no idea how CMake works], so that it always has to be specified by whoever is doing the compiling to make sure it's done correctly.)

You're demanding someone else do it for you.

You gave yourself away here. Go troll someone else - I've never demanded or even asked anyone to undertake any work because of the reasons I already outlined for needing acceptance of the concept and direction from the DFHack team first.

[salithus]

Double post.

[Rumrusher]

It really comes down to how you want people who are compiling themselves to do it. When I did it with .40.12, I just followed the step by step instructions because it was my first time. With .40.13, I did the master branch thinking it'd prove more of a point about how close the DF code was across the 3 releases and I didn't want to unknowingly include active development that might address an issue I wasn't aware of. Whichever I should be compiling against, that's the one I recommend not have an official version string as the default. (Might even be worth taking those lines out of source control entirely somehow [addmittedly no idea how CMake works], so that it always has to be specified by whoever is doing the compiling to make sure it's done correctly.)

uhh through IRC? kinda find the idea that if anyone willingly set on building dfhack and compiling a (dev/branch/copy/early access) build should hang out with the devs and listen to them discuss builds and plugins.
like you cross the step from being a user of dfhack to being a developer and drank the darkspawn blood and finally become a Git Warden, now shall wait out your continuous life in Freenode dusting the giant ruins of DF to unearth more stuff for the wizards of the camp to craft wonderful spells or trinkets of either entertainment or ease of use. This quest is a long and repeating one that has it's ups and downs, but's thats the life of a git warden. jokes aside that sounds like alot of effort to do in the middle of a dev cycle that updates around in weeks and that whole dfhack shouldn't cause people to wait out for the new update of DFH to play the new update of DF.

then again this is a opinion from a guy who writes scripts(lua) all day and too lazy or/and incompetent to write a solution that doesn't end with rewriting everything. Take with a grain of salt.