Compiling errors of doom, destruction, and doom.

[Dimentio]

Repost from Pure:



The errors I got:

-=SPOILER=-


Continued...



-=SPOILER=-

Post too long, continuing in the next post...

Continued...

Errors:

-=SPOILER=-


Welcome back to AGN Z! This time: Will AGN finish charging up it's Kame-Hame-PostTooLong? Find out NOW!



-=SPOILER=-

These were the errors that stopped my compiling.

Also, I got some warnings that didn't stop the compilation, but I'll post here just in case:
-=SPOILER=-

[ZoriaRPG]

That's 'Doom, Demise, and Destruction'.

I'll point out, that it could be my fault for suggesting that you use the 'Minimal' version of Boost. It looks as if the parser can't comprehend some things that it should, except that VS2008 doesn't natively do CPP11, which is why Boost is mandatory.

Let's try it with the full version of boost, 1.62.0, and see if that solves it.

[DarkDragon]

First, you don't have to paste all of the errors; the first few errors are usually enough to find the problem (and the rest are just cascading errors caused by the first errors, etc etc).

Second, please indicate which branch of the code you're trying to compile (and if it's not the head, also the revision). I assume you're trying to compile the latest revision of branch 2.50.x, since on the master branch TRACER is still named MATRIX_TRACER and there is presumably no conflict.

Now as to your compile issue: somehow the compiler is seeing a previous definition of TRACER somewhere. In the ZC source TRACER appears as an enumeration constant in ffscript.h, but it's not clear to me how ffscript.h is being included in matrix.cpp; this will require some detective work.

You haven't modified any of the code, correct? In particular you haven't added any new #includes anywhere?

[Dimentio]

First, you don't have to paste all of the errors; the first few errors are usually enough to find the problem (and the rest are just cascading errors caused by the first errors, etc etc).

Second, please indicate which branch of the code you're trying to compile (and if it's not the head, also the revision). I assume you're trying to compile the latest revision of branch 2.50.x, since on the master branch TRACER is still named MATRIX_TRACER and there is presumably no conflict.

Now as to your compile issue: somehow the compiler is seeing a previous definition of TRACER somewhere. In the ZC source TRACER appears as an enumeration constant in ffscript.h, but it's not clear to me how ffscript.h is being included in matrix.cpp; this will require some detective work.

You haven't modified any of the code, correct? In particular you haven't added any new #includes anywhere?

No, the code is freshly installed from the 2.50.x github. I'm currently installing the full version of boost to see if that fixes the problem, but if not then I'm not sure :l

[DarkDragon]

I don't know why Boost would cause these errors, especially as Boost is used nowhere near Matrix.cpp. But I suppose installing it can't hurt?

Which version of Visual Studio are you using? And are you using the solution file from projects/vs2008, or something else?

[ZoriaRPG]

I don't know why Boost would cause these errors, especially as Boost is used nowhere near Matrix.cpp. But I suppose installing it can't hurt?

Which version of Visual Studio are you using? And are you using the solution file from projects/vs2008, or something else?

He's using the project and solutions from ./projects/vs2008 in VS2008. I sent him a full copy of it as a gift, when he decided that he wanted to work on the thing. :)

The project file does have an issue though, that I flagged on GitHub: It's calling for files under ./src/build_modules/*

That path is not in the 2.50.x branch, so I suggested that he grab those files (and only those files) from the 'master' branch. It's possible that they differ.

It may also be that when he added include paths, that he accidentally added something from 'master' to them, and that may be causing conflicts.

Anyhow, boost is sadly mandatory with VS2008, as it doesn't support cpp11, and the source needs one, or the other.

I'm sort of thinking to suggest that he put VNC Server on his laptop for a day, so that I can remote in, clean up the repo on his local system, set up the include paths, and fix it, but I don't want to suggest that unless it's the only recourse.

[Saffith]

The 2.50.x branch doesn't need any boost stuff.
Gleeok's the one who uses VS; I don't know anything about it. I still have the project files from the old repo, and I don't think there have been any changes that would invalidate them. I'll try replacing them in a bit. (I just have to hope they'll keep their line endings, because hey, no .gitattributes.)

[Gleeok]

The VC++ project files for 2.50 are not compatible with with the trunk VC++ project files. This is because 2.50 was tagged before I refactored some of the ZC code, put in more defined translation units, and fixed (some of) the global namespace pollution problem. Please use the project files from the 2.50 branch.

Disclaimer: I have never tried to compile the 2.50 code on anything higher than MSVC 2010;

[Saffith]

They're the same in both branches, is the thing. The 2.50.x branch has the project files from master. The proper project files never went to git in the first place.

Edit: Hm, nope, the ones from the old repo don't have the sound library separated out. That may not really matter, though...
Well, they're less wrong, at least. I'll put them up, and I guess they can get fixed or whatever.

[ZoriaRPG]

Saffith: I presume that you are using the makefile, which is what I was originally suggesting that Dimentio use. For Widows builds, are you using NMake, gcc (via CygWin), or something else? It would be helpful to know what you are using, as in any other situation, it should also work.
Gleeok: Is there any chance you can make a VS2008 Solution for the 2.50.x branch that is up to date with the repository?

Also, DarkDragon asked me about using VS2015. I seem to recall that Gleeok said that Microsloth changed something in VS2012 and later that made compiling in those newer versions impossible; and that it had something to do with how VS sees file paths. Is that right? I've never used a version newer than 2010, and the only full version that I have is 2008, so I'm not sure what broke.

[Gleeok]

Also, [MENTION=1]DarkDragon asked me about using VS2015. I seem to recall that Gleeok said that Microsloth changed something in VS2012 and later that made compiling in those newer versions impossible; and that it had something to do with how VS sees file paths. Is that right? I've never used a version newer than 2010, and the only full version that I have is 2008, so I'm not sure what broke.

I don't remember saying anything like that. AFAIK it might just work. ..?
I said I could put up 2010 files, but I didn't want to maintain two seperate projects, and if I switched to 2010 then support for 2008 would drop, so..

The project from shardstorm should work if the other one doesn't; nothing's really been changed. (Have I mentioned that I only work with the current code?)

[DarkDragon]

What is the "current code"? The github master branch?

[Gleeok]

Yeah, I don't even have a local checkout copy of the github 2.50.x branch. I don't think it's it's been up there very long.

The trunk should compile fine, unless you have 2015 and are trying to compile for 64-bit, then I'm not so sure. People have had trouble with this. Also there are no projects for the 3rd party libs, so from the perspective of having to do a complete setup and rebuild it's a bit of a clusterfuck - and not the good kind either.

[DarkDragon]

Dimentio: so after investigation, my conclusion is that the MSVC solution file in 2.50.x is out of date. Trying to copy files out of the master branch will NOT fix the problem. The easiest way forward is to compile the master branch rather than 2.50.x. If you want to fix 2.50.x, you will have to change the solution files so that each of the four projects correctly compiles the right subset of the source files (currently they are configured to use the "module" system of the master branch, which does not exist in the 2.50.x branch).

[Gleeok]

I thought Saffith said he changed the 2.50.x ones but I guess not. I'll see if I can get the old files out of the archive and put them up today. (If no one else beats me to it that is)

[side note] Even if you set up the build modules correctly for the 2.50.x branch it will not compile. This is because the master has had the benefit of some refactoring since 2.5.

[Saffith]

I did, but they may need updated.

I'm not sure there's any sense trying to use the master branch right now. It's gotten messy, and I think it's just going to be abandoned.


Saffith: I presume that you are using the makefile, which is what I was originally suggesting that Dimentio use. For Widows builds, are you using NMake, gcc (via CygWin), or something else? It would be helpful to know what you are using, as in any other situation, it should also work.
MinGW in MSYS.

[ZoriaRPG]

I did, but they may need updated.

I'm not sure there's any sense trying to use the master branch right now. It's gotten messy, and I think it's just going to be abandoned.


MinGW in MSYS. Gleeok
We needn't drop support for vs2008 just to add 2010 support. Those can coexist.
Saffith
That would require merging all the bitmap changes with 2.50.x, and Gleeok did all of those. I know that he added bitmap creation, at the least, and reorganised some bitmap usage.

FWIW, 2.50.3 should be the master, and anything new and experimental should be a branch, merged into the master when it is known to work.

Gleeok Are you sure that the ffscript symbol tables will compile? I thougjt that I saw an error in there. I have fixed versions of the tables though, for DrawBitmapEx args and such.

[Saffith]

Well, that's why we have git-merge.

[Gleeok]

I'm not sure there's any sense trying to use the master branch right now. It's gotten messy, and I think it's just going to be abandoned.


-_- ... what ...


What do you plan on leaving out amongst all the changes since 2.50?

[Saffith]

What's worth keeping? Let's throw out everything but that.

[ZoriaRPG]

First, what specifically do you consider messy, about it? I have no changelog to reference, but there are quite a lot of subtle things that I've noticed, that may, or may not be easy to just merge across. (This is why keeping some kind of active log, other than doing a diff is usually a good idea...)

Can we possibly worry about this, after we ensure that people can use both repositories? I think cleaning house with the repos has a bit more priority, than worrying about if we're keeping the master branch. Admittedly, I haven't gone through the pulls other than stuff that Gleeok did, so I don't know what the big offenders are; and I'm not againstusing 2.50.3 to start the changes, as the master branch now lacks the bugfixes in 2.50.3.

We could ice both as branches, make a 2.50.3 master with clean vs files, verified makefiles (checking LF and such), and some basic compiling info, as a new 'master', and roll things from the old master into it the new '2.5+ branch' of 2.50.3, so that 'master' is always the current binary; which is how I understand that Git is supposed to be used, and something that most people would comprehend. That way, we preserve the changes in the present master branch for inclusion, keep a clean 2.50.3 snapshot, and have a working 2.5+ branch.

Once we know that anyone can download, compile, and go, and I make up some docs for compiling--because I know this probably falls under my job description, and I'll be stuck making them--I think that things will go smoother.

My tuppence worth.

[DarkDragon]

Can you explain a bit what went wrong in the master branch? There was some experimental refactoring that didn't end up helping?

[DarkDragon]

First, what specifically do you consider messy, about it? I have no changelog to reference, but there are quite a lot of subtle things that I've noticed, that may, or may not be easy to just merge across. (This is why keeping some kind of active log, other than doing a diff is usually a good idea...)

Can we possibly worry about this, after we ensure that people can use both repositories? I think cleaning house with the repos has a bit more priority, than worrying about if we're keeping the master branch. Admittedly, I haven't gone through the pulls other than stuff that Gleeok did, so I don't know what the big offenders are; and I'm not againstusing 2.50.3 to start the changes, as the master branch now lacks the bugfixes in 2.50.3.

We could ice both as branches, make a 2.50.3 master with clean vs files, verified makefiles (checking LF and such), and some basic compiling info, as a new 'master', and roll things from the old master into it the new '2.5+ branch' of 2.50.3, so that 'master' is always the current binary; which is how I understand that Git is supposed to be used, and something that most people would comprehend. That way, we preserve the changes in the present master branch for inclusion, keep a clean 2.50.3 snapshot, and have a working 2.5+ branch.

Once we know that anyone can download, compile, and go, and I make up some docs for compiling--because I know this probably falls under my job description, and I'll be stuck making them--I think that things will go smoother.

My tuppence worth.

I think I agree with what you're saying -- I was expecting
- a master branch containing the latest development binary (features that are more-or-less stable and cleared to ship with the next version of ZC)
- a branch for minor revisions of old-yet-still-supported major releases of ZC (to which some bugfixes in the master are back-ported as needed)
- several branches for experimental features/risky refactorings (to be merged into master when they're deemed ready and successful)

But there are any number of other sane ways to organize the repository. I'm mostly confused about the fact that currently there are two branches, and for both branches there are claims that (i) this branch contains the latest code and (ii) this branch is about to be deleted. :confused_white:

[Gleeok]

I'd like to take a minute to get everyone to take a step back and try and get on the same page here. Most of us (myself included) have been on a hiatus for varying lengths of time, so I think that would be the most prudent thing to do.


Merging the two branches sounds fine: If none of the major refactoring work is going to help anything in the long run, or, there's better alternatives, etc. then it's probably better to do it sooner than later. Besides the obvious stuff you [@Saffith] want to throw out or redo, there may be a decent amount of small changes that are worth keeping. I guess what I'm saying is have a little bit of optimism when merging, if that makes sense.

[DarkDragon]

Can you explain a bit what is in the master branch that should be "thrown out" and why (and conversely, what has been added to the branch that you think should be kept)? I'm looking at the revision history and it seems like the vast majority of commits are bug fixes that were applied to both branches.

[ZoriaRPG]

I'd like to take a minute to get everyone to take a step back and try and get on the same page here. Most of us (myself included) have been on a hiatus for varying lengths of time, so I think that would be the most prudent thing to do.


Merging the two branches sounds fine: If none of the major refactoring work is going to help anything in the long run, or, there's better alternatives, etc. then it's probably better to do it sooner than later. Besides the obvious stuff you Saffith] want to throw out or redo, there may be a decent amount of small changes that are worth keeping. I guess what I'm saying is have a little bit of optimism when merging, if that makes sense.

Was the optimism thing aimed at me, or Saffith? I have no objection to merging them: I'm just uncertain what Saffith has problems with in the master branch, and I don't know how smoothly integration would be, but if we can keep all the new features that you added, merging them with the 2.50.3 bugfixes, either way, it would be good, and it's pretty bloody crucial. :)

I had been expecting the merge to go the other way, TBH.

I never did get an answer to your concern from many months ago that some of my drawing functions migt be problematic with how you reworked the bitmap targets, or if they would at all; or if you meant something else might cause crashes.


I think I agree with what you're saying -- I was expecting
- a master branch containing the latest development binary (features that are more-or-less stable and cleared to ship with the next version of ZC)
- a branch for minor revisions of old-yet-still-supported major releases of ZC (to which some bugfixes in the master are back-ported as needed)
- several branches for experimental features/risky refactorings (to be merged into master when they're deemed ready and successful)

But there are any number of other sane ways to organize the repository. I'm mostly confused about the fact that currently there are two branches, and for both branches there are claims that (i) this branch contains the latest code and (ii) this branch is about to be deleted. :confused_white:

I'm pretty certain that this is what most people expect. The present organisation is abnormal, to say the least, and IMO, anything new, or experimental should be in a branch, or a fork, so that it's easy for a prospective party to know what is stable, and the present binary; which isn't actually up there at all. 2.50.3 will go Gamma, but the latest stable is still 2.50.2.

it's not critical to change that, at present, but in the future, it would probably encourage more participation if we organised it on the same scheme as other open-source projects typically follow. Sanity, and all.


Can you explain a bit what is in the master branch that should be "thrown out" and why (and conversely, what has been added to the branch that you think should be kept)? I'm looking at the revision history and it seems like the vast majority of commits are bug fixes that were applied to both branches.

Pretty much, what I was asking above, or possibly more to the point. I looked over the bugfix history on 2.50.x last week, but I neglected to do it with the 'master' branch.

I'm going to need to borrow some bandwidth, pull my VS image off the server onto this laptop, and see if master does in fact compile as-is from the project file: I prodded Dimentio to try, as he has the VS2008 installed that I sent to him, and it's up and running, but I don't believe he has tried yet. I'll also try to do a writer-up for compiling with MinGW, and see if I can do likewise for CygWin. I do not have Linux with me--well, I did, but it was on a USB pen drive that vanished--so I can't do a Linux gcc test.

-------------
Saffith: I shoved MSYS onto this machine, and I tried using the makefile with a simple make invocation. I have the allegro directory both in x:/zc2.50.x/allegro and in x:/MinGW/msys/1.0/include/allegro

The make operation halts with: In file included from src/zcmusic.cpp:13:0: src/zc_alleg.h:16:21: fatal error: allegro.h No such file or directory.

http://timelord.insomnia247.nl/zc/zc_dev/zc_make_error.png

Where does MSYS expect the allegro files to be located? Looking at the makefile, there is no special include path set for them.

Ordinarily I would expect that the makefile should run with all the mandatory includes, libs, and other files from relative paths to it, but this seems not to be true; unless you are using some parameter / option with the make invocation?

This is using the 2.50.x branch.

[ZoriaRPG]

I added includes for allegro directly in the makefile ( see: http://pastebin.com/5TpvZnqr ) . I also added ./Include

Revised Makefile
-=SPOILER=-

Many warnings, and the repo is missing zmusic.o.

The code calls for objects under ./obj/* ... These are not in the repository.

[Saffith]

I don't know. Some of it's all right, I guess. Everything under dialog/, gui/, and sequence/ is garbage. Some of the changes to Link don't work right. The changes to items and rooms are mostly stupid and currently broken. Various refactorings and rewritings are just awful.


Where does MSYS expect the allegro files to be located? Looking at the makefile, there is no special include path set for them.
Somewhere on the include paths. Allegro's make install should put them where they need to be, assuming you set MINGDIR correctly.


The code calls for objects under ./obj/* ... These are not in the repository.
Object files are built by the compiler.

[Gleeok]

I don't know. Some of it's all right, I guess. Everything under dialog/, gui/, and sequence/ is garbage. Some of the changes to Link don't work right. The changes to items and rooms are mostly stupid and currently broken. Various refactorings and rewritings are just awful.


Ah, got it. I haven't looked too much at those things directly but I understand now. Is it strange that I somehow didn't encounter any of those bugs?

[ZoriaRPG]

I don't know. Some of it's all right, I guess. Everything under dialog/, gui/, and sequence/ is garbage. Some of the changes to Link don't work right. The changes to items and rooms are mostly stupid and currently broken. Various refactorings and rewritings are just awful.


Somewhere on the include paths. Allegro's make install should put them where they need to be, assuming you set MINGDIR correctly.


Object files are built by the compiler.

It was because there was no 'obj' directory path in which to build it...and the makefile isn't generating it.

Does MSYS have an option for Make to output all warnings, and errors to a text logfile? Unfortunately, MSYS does not allow click selection of text in its terminal window.

I've tried the typical Linux things:
make > logfile.txt >2&1
make logfile.txt |

No positive results, and there is a steady strea of warnins that you may wish to note.

Even the makefile above halts with include errors, and I had to further dump the includes to:

drive:\MinGW\lib\gcc\mingw32\5.3.0\include

That is apparently the default include path for MSYS, not ( drive:\MinGW\include ).

I further had to create the path ./obj/parser

It did compile, and the binaries do run.; although zlaunch.exe was not generated by it.

[ZoriaRPG]

Here's that guide for using MSYS:

http://pastebin.com/Ygxqe0av

Building ZC With MSYS
-=SPOILER=-

P.S. I tried merging Gleeok's new drawing stuff, but msys/gcc continuously gave me a nonspecific error generating ffscript.o. I'll re-try, tomorrow, one new entry at a time.

[Gleeok]

Alright, I went ahead and abandoned the master branch since I don't think I had anything that important in there (..I'll look at it later, anyway). It would be nice to keep the build_modules stuff though, if you don't mind merging the seemingly nothing namespace fixes, etc. over when it happens.