Angband.oook.cz
Angband.oook.cz
AboutVariantsLadderForumCompetitionComicScreenshotsFunniesLinks

Go Back   Angband Forums > Angband > Development

Reply
 
Thread Tools Display Modes
Old February 14, 2020, 23:21   #11
Nick
Vanilla maintainer
 
Nick's Avatar
 
Join Date: Apr 2007
Location: Canberra, Australia
Age: 54
Posts: 8,243
Donated: $60
Nick will become famous soon enough
Quote:
Originally Posted by AnonymousHero View Post
This is exactly why Angband should just bite the bullet and move to CMake. It'll happily generate solution files, etc. I've offered to help before, but it fell on deaf ears
So we have had our current build system since well before my time, and it works for all the things we need it to work for (basically), and this stuff is not my strong suit so I'm disinclined to (or maybe afraid to) change it.

If anyone who knows more about the current system wants to discuss the pros and cons, I'm happy to watch.
__________________
One for the Dark Lord on his dark throne
In the Land of Mordor where the Shadows lie.
Nick is offline   Reply With Quote
Old February 15, 2020, 00:20   #12
Pete Mack
Prophet
 
Join Date: Apr 2007
Location: Seattle, WA
Posts: 5,698
Donated: $40
Pete Mack is on a distinguished road
Nick-
The current system was done by yours truly circa 3.1, not all too many years before your time. I cleaned up a bunch of standard makefiles and added the include files for portability. That said, I truly don't understand autoconf, which seems like black magic to me.
Pete Mack is offline   Reply With Quote
Old February 15, 2020, 18:18   #13
AnonymousHero
Veteran
 
AnonymousHero's Avatar
 
Join Date: Jun 2007
Posts: 1,372
AnonymousHero is on a distinguished road
Oh, it works and has been working except when it doesn't :|... See title of this thread.

Advantages for CMake are:
  • isn't automake/autoconf. I'm sure Pete will back me up on this... Auto* is a hellscape of bizarre compatibility nonsense going back to SunOS and similarly absurdly outdated/dead platforms. It's also totally inscrutable because it's basically a bizarre blend of m4 + Shell script, and it requires EXTREME care to be compatible with POSIX shell.
  • can generate makefiles, ninja files, IDEs like qtcreator (and VS code?) use and understand these files. No idea if VS code understands CMake files, but at least CMake can generate Solution files, which was a big point in this thread. (Committing solution files to the repo. That's an antipattern unless you're purely going to use MSVC/whatever.)

(I'm sure I missed out on something... just addressing the points raised in response to my post.)
AnonymousHero is offline   Reply With Quote
Old February 15, 2020, 22:22   #14
Pete Mack
Prophet
 
Join Date: Apr 2007
Location: Seattle, WA
Posts: 5,698
Donated: $40
Pete Mack is on a distinguished road
Took a look at the CMake examples. Looks very nice. I just did as much as I could with ordinary makefiles--making them reasonably clean and as portable as possible. I also don't like ./configure, either. Real mystery when it doesn't work; I'd much rather a system that knows the details of target OS, and doesn't make guesses.
Pete Mack is offline   Reply With Quote
Old February 16, 2020, 04:23   #15
eastwind
Apprentice
 
Join Date: Dec 2019
Location: Mexico, undisclosed location
Posts: 79
eastwind is on a distinguished road
I don't think the fact that I made angband build with VS is a good argument for switching to CMake. Rather, it's a good argument for not using CMake. Anyway, CMake is a different discussion for a different thread.

The argument about flattening the VS build hierarchy so that the solution and project sit in the same directory comes up every single time (not just Angband, it comes up *every* time you create a VS build for something that had another build first). I believe there are several good reasons for using the two-level directory hierarchy, and no *good* reasons for not using it.

First is the way VS handles 'intermediate' files, those files created by the build which are not necessary to 'ship', for example, all the .obj files. If you flatten the hierarchy, by default the intermediate output directory ends up being the same as the final output directory, and the stuff you need to ship gets mixed with the stuff you don't. That is, the IntermediateOutputDirectory ends up being the same as the OutputDirectory, and issues ensue. You can override those, but then other issues ensue that you have to work through. I have been down this road before, and it's more difficult overall.

Another reason is that, by design, a VS 'Solution' is intended to encapsulate multiple different projects related to the same larger 'thing'. An example of this is in fact used by Angband - the test file stuff. I didn't make that work, but if I had wanted to, there would be a Test.vcxproj in a Test folder underneath the solution folder, and Test would be a peer to the Angband folder with the Angband.vcxproj. The way it is set up now, if somebody wants to come along and create some kind of add-on executable that builds separately from Angband.exe they can easily do so, within the VS model.

It's important to understand that the VS build system model uses a 1:1 mapping between a .vcxproj and an .exe (or .dll) output file. If you want to ship multiple executables, the VS model is you have one project per executable that you want to ship. The build system is set up to build all the stuff associated with a single executable (like debug symbol files, map files, etc etc) along with the executable, but trying to get a .vcxproj to build two .exes just doesn't work unless you simply don't use the VS MSbuild and have it run a makefile instead, in which case you lose a lot of the goodness of VS.

You don't, under the VS build model, want to put multiple .vcxproj's in the same folder, because then the two projects try to build intermediates into the same subfolders of that, and chaos ensues. So the flat hierarchy only works if you only *ever* want to build a single executable. So if you start off that way (with a flat hierarchy), you close off future options.

You can make a single level hierarchy work. You're starting with something designed to work one way and bashing it into another form, and with enough bashing you can get it to work, at least until some kind of new change comes along (either in your requirements, or in VS). It's more work to make it work, you have a less-ideal build when you're done, and it's more brittle. But it satisfies the people who really want to 'be like' make. The cost of doing this, both in getting it working in the first place and in using it and maintaining it over the long haul, is really far beyond the benefit. I don't think wanting to 'be like' the other builds is a good reason for doing it, given the costs. It's not genuinely simpler.

I used VS to build various projects extensively from 2005-2016, and I have gone down the 'flat build' path a time or two on my own, thinking it would be simpler and easier for a given little project, only to end up changing back to a multi-level build later for at least two different solutions. Never again. Sooner or later you always end up paying a big penalty for not coloring within the lines on this issue.
eastwind is offline   Reply With Quote
Old February 16, 2020, 21:13   #16
Siemelink
Rookie
 
Join Date: Feb 2014
Location: Hungary
Posts: 18
Siemelink is on a distinguished road
Hi Eastwind,
thanks for the docs, I managed to compile as well. Now I need a purpose!

Regards, Willem.
Siemelink is offline   Reply With Quote
Old February 18, 2020, 22:51   #17
Gwarl
Knight
 
Join Date: Jan 2017
Posts: 843
Gwarl will become famous soon enough
All I ask is that nobody removes the ability to simply
Code:
make -f Makefile.std
from anything. Please.
Gwarl is offline   Reply With Quote
Old February 19, 2020, 13:09   #18
Pagaronn
Rookie
 
Join Date: Jan 2020
Location: Montreal
Posts: 7
Pagaronn is on a distinguished road
follow up

Sorry eastwind, I did not do any followup since my offer to help. I felt overwhelm to get the project - I was not sure how so I went back at playing UnAngband instead with my free time.
Pagaronn is offline   Reply With Quote
Old February 21, 2020, 13:31   #19
AnonymousHero
Veteran
 
AnonymousHero's Avatar
 
Join Date: Jun 2007
Posts: 1,372
AnonymousHero is on a distinguished road
Quote:
Originally Posted by eastwind View Post
I don't think the fact that I made angband build with VS is a good argument for switching to CMake. Rather, it's a good argument for not using CMake.
The mere fact that you even had to work to make Angbuild build with VS is an argument for CMake (or whatever other non-make non-auto* system that is actually somewhat sane -- I only mention CMake because I'm familiar with it and have used it quite happily with T2. Most IDEs I've tried also have decent-to-good support for it -- which is not the case for make-based systems.). It should have just worked out of the box.

... but never fear. I have no intention of pressing the issue. (Nor could I.) I just wanted to mention that these issues are indeed soluble and should be non-issues.
AnonymousHero is offline   Reply With Quote
Old May 4, 2020, 08:31   #20
WindLord
Rookie
 
Join Date: Dec 2019
Posts: 3
WindLord is on a distinguished road
Success

I successfully got your image to compile and run. It took a couple times and finally matched your directory structure.
The instructions seem to show two ways to do stuff. One is use directly from the GIT master and the other is to use your VS project.

Your build seems slower than the Windows EXE available for download.

Do you know if your image includes the update for the Quiver changes? I play as Ranger and this is of interest to me.

Thank you for getting this up.
Rick
PS: I downloaded the Master, and all compiled. But when I try to run it, the different windows come up and stay for about two seconds then the program shuts down.
Figure I overwrote a file that should not have been changed. And suggestions where to start looking?
Thank you

Last edited by WindLord; May 4, 2020 at 10:09.
WindLord is offline   Reply With Quote
Reply


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
First Post: Introduction and test Monkay Vanilla 18 January 5, 2012 15:16
[Un] beginner advice solicited radical_green Variants 10 February 7, 2010 01:56
Pointers/Advice solicited on creating Angband solution inside VC++ 2008 Express jojojajumbo Development 5 August 5, 2009 03:21
Test-Id for armor Donald Jonker Vanilla 3 May 20, 2009 10:00
VB formatting test Leon Marrick Idle chatter 13 April 30, 2007 19:26


All times are GMT +1. The time now is 06:41.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.