Building on Mac and Linux

[Grayswandir]

@ZoriaRPG - ZC has always had the current dev branch as main in the past; we're just used it I guess. For everyone else bitching about it during the holiday season remember that it's the holidays. Please stop bitching about it. Just swapping A<-->B around in the repo doesn't do anything. It needs some elbow grease as well. Thank you come again.

It would've saved me the trouble of getting master working, only to realize that nobody's actually using it.

I wasn't complaining. I was just responding to the "how could you possibly think nothing is happening?" sentiment, since the answer was pretty obvious from my perspective. Again, my point wasn't that you should do it, but that since it's so easy and you aren't doing it, I am obviously completely disconnected from everything and have no clue what's going on.

You know, like I said in every post I made in this thread.

[Gleeok]

LINK : fatal error LNK1104: cannot open file 'legacy_stdio_definitions.lib'

LINK : warning LNK4075: ignoring '/INCREMENTAL' due to '/LTCG' specification
LINK : warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs; use /NODEFAULTLIB:library

LTCG in debug is crazy sauce.

edit:

2>loadpng.lib(regpng.obj) : MSIL .netmodule or module compiled with /GL found; restarting link with /LTCG; add /LTCG to the link command line to improve linker performance
2>LINK : warning LNK4075: ignoring '/INCREMENTAL' due to '/LTCG' specification
2>LINK : warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs; use /NODEFAULTLIB:library

4>ffscript.ypp(596) : error C3861: 'snprintf': identifier not found

It would've saved me the trouble of getting master working, only to realize that nobody's actually using it.

I wasn't complaining. I was just responding to the "how could you possibly think nothing is happening?" sentiment, since the answer was pretty obvious from my perspective. Again, my point wasn't that you should do it, but that since it's so easy and you aren't doing it, I am obviously completely disconnected from everything and have no clue what's going on.

You know, like I said in every post I made in this thread.

It's okay, nobody else knows what is going either.

[DarkDragon]

I can fix the library issue but I don't remember the snprintf workaround. Do you know how you're fixing it in your project file?

[Gleeok]

Oh, I was just copypasta there. It's _snprintf for some reason.

[Gleeok]

Okay, on to the linker now.

Fixing legacy_stdio_definitions.lib should also fix zcsoundlib.
LINK : fatal error LNK1104: cannot open file 'Debug\zcsound.lib'

Once these link I'll test this on MSVC 2010 as well. I can also do 2013 if you like, though maybe another day.

[DarkDragon]

I've pushed a fix for the libraries. Can you to regenerate/rebuild?

I'm guessing you will still get the _snprintf error though. Do you know how you fixed that?

EDIT: Oh never mind looks like you already added the necessary #defines.

[DarkDragon]

It's okay, nobody else knows what is going either.

Let's get to the bottom of things then...

My understanding (and correct me on any point that is wrong):
1. The public releases of ZC lately (2.50.3, etc) have been based on the 2.50.x branch of the repository.
2. Independently, Gleeok and others have been committing new features/fixes to the master branch of the repository.
3. The master branch contains many valuable changes.
4. The master branch also contains some changes that are considered by Saffith (and perhaps other) as "garbage."
5. 2.50.x contains changes that have not been applied to master.

So where does that leave us? Clearly 2.50.x (with cleanup which we're currently undertaking) must become the master branch, since that is the branch from which public binaries are actually being published. We cannot use the code from the current master branch for at least two reasons:
- it is not in sync with the current publicly-released binaries;
- some of the changes are "garbage" and need to be reconsidered.

Hence the plan to make 2.50.x the new master, and to look through the current-master changes and incorporate those that are worthwhile, while avoiding the garbage. Once that is done, the repository will be in a healthy state and we can start e.g. discussing changing the Allegro version or pulling in some of ZoriaRPG and Grayswandir et al's changes.

If I've gotten something wrong or you disagree with any of the above, by all means, please let me know.

[Gleeok]

I've pushed a fix for the libraries. Can you to regenerate/rebuild?

I'm guessing you will still get the _snprintf error though. Do you know how you fixed that?

EDIT: Oh never mind looks like you already added the necessary #defines.

I've got it compiled for 2008. I'll try 2010 and also update the source later with my changes. Congrats, you are the first person in the history of CMAKE to actually make some c++ nonsense work. (Not joking, it's always usually awful) Thanks!

(Although the build times are too long,~I can just fix that later.)

Let's get to the bottom of things then...

My understanding (and correct me on any point that is wrong):
1. The public releases of ZC lately (2.50.3, etc) have been based on the 2.50.x branch of the repository.
2. Independently, Gleeok and others have been committing new features/fixes to the master branch of the repository.
3. The master branch contains many valuable changes.
4. The master branch also contains some changes that are considered by Saffith (and perhaps other) as "garbage."
5. 2.50.x contains changes that have not been applied to master.

So where does that leave us? Clearly 2.50.x (with cleanup which we're currently undertaking) must become the master branch, since that is the branch from which public binaries are actually being published. We cannot use the code from the current master branch for at least two reasons:
- it is not in sync with the current publicly-released binaries;
- some of the changes are "garbage" and need to be reconsidered.

Hence the plan to make 2.50.x the new master, and to look through the current-master changes and incorporate those that are worthwhile, while avoiding the garbage. Once that is done, the repository will be in a healthy state and we can start e.g. discussing changing the Allegro version or pulling in some of ZoriaRPG and Grayswandir et al's changes.

If I've gotten something wrong or you disagree with any of the above, by all means, please let me know.

That's basically what I was thinking.

[DarkDragon]

Thanks Gleeok! Let me know if you run into any new trouble with 2010.

ZoriaRPG, you mentioned that you used a Mac. Do you have time to take a stab at adding OS X support to CMakeLists.txt? I know that OS X uses -frameworks and all kinds of other delights I'm ignorant about :-/

[Gleeok]

On VC 2010 I get a wall of

C:\Program Files\Microsoft Visual Studio 10.0\VC\include\stdint.h(59): error C2628: '_Longlong' followed by 'signed' is illegal (did you forget a ';'?)
C:\Program Files\Microsoft Visual Studio 10.0\VC\include\stdint.h(59): error C2628: '_Longlong' followed by '__int64' is illegal (did you forget a ';'?)
C:\Program Files\Microsoft Visual Studio 10.0\VC\include\stdint.h(59): warning C4091: 'typedef ' : ignored on left of '__int64' when no variable is declared
C:\Program Files\Microsoft Visual Studio 10.0\VC\include\stdint.h(60): error C2628: '_ULonglong' followed by 'unsigned' is illegal (did you forget a ';'?)
C:\Program Files\Microsoft Visual Studio 10.0\VC\include\stdint.h(60): error C2628: '_ULonglong' followed by '__int64' is illegal (did you forget a ';'?)
C:\Program Files\Microsoft Visual Studio 10.0\VC\include\stdint.h(60): warning C4091: 'typedef ' : ignored on left of 'unsigned __int64' when no variable is declared

I'm 2/2 on here and I also had this problem on the trunk once. IIRC so did someone else. It's defining those AND then including stdint.h (Which I believe is included as part of the c library by clib headers.) The astdint.h file is to blame. If anyone ever includes any other reasonable header after an allegro header this is going to happen.

If there's no problem I'd like to remove that and force users to have stdint.h. For MSVC 2005/2008 I can add a suitable al_stdint.h into the allegro/platform folder.


[EDIT] Nevermind. That did not work. Seems to only be 64 bit types (I missed that - Doh!). Now who's the culprit here...