User Tag List

Page 1 of 7 1 2 3 ... LastLast
Results 1 to 10 of 62

Thread: CMAKE Branch

  1. #1
    Mad, Mad, Author ZoriaRPG's Avatar
    Join Date
    Oct 2006
    Location
    Prydon Academy
    Posts
    763
    Mentioned
    68 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    2,926
    Level
    17
    vBActivity - Bars
    Lv. Percent
    54.58%
    Daily Activity
    0%
    Weekly Activity
    10%
    Monthly Activity
    149.18%

    CMAKE Branch

    I'm not an expert in CMAKE directives, but it reads to me as if all the MSWIN directives are for SVC., not for gcc/MSYS.

    Would it be possible to throw a basic makefile for gcc into that branch, please; or at least clarify that the CMAKE file has been tested on that configuration.

    I also wish to point out a slew of missing files:

    libzcsound.dll, compiled for allegro 4.4, is missing, as are all of the *.a files for ag4.4. These should be in the libs/mingw path, but all of the files there are the old 4.4 files that Saffith last pushed on 3rd December, 2016. Those need updating to whatever you compiled. Putting all of the allegro deps in the package, or in a separate package, so that it is not mandatory for everyone to compile that beast and all its dependencies would be very useful, indeed.

    As-is, I don't see how this can generate a makefile for mingw.
    Last edited by ZoriaRPG; 12-30-2016 at 08:49 AM.


    Script Headers: RPG.zh ( v. a0.97.1 ) ( RPG.zh Thread ) | stdArguments.zh (v.6.9.9/1) | | Timers.zh (v.1.5)
    ZScript | ZC Dev | ZC 2.53 | Alucard's: stdCombos.zh (v1.1) | stdWeapons.zh | particles.z
    All of the code that I create and publish here is free for use, modification and distribution under the GPL v2.0.

  2. #2
    Developer ZC Developer
    Gleeok's Avatar
    Join Date
    Apr 2007
    Posts
    4,610
    Mentioned
    206 Post(s)
    Tagged
    10 Thread(s)
    vBActivity - Stats
    Points
    12,129
    Level
    32
    vBActivity - Bars
    Lv. Percent
    35.09%
    Daily Activity
    0%
    Weekly Activity
    10%
    Monthly Activity
    405.59%
    We've been testing cmake on all the compilers that we could so far; MSVC 2008, 2010, 2013, 2016, and gcc 5.4. This obviously doesn't necessarily mean that it works on every other platform/toolchain, but any feedback you guys could give would be very much appreciated. Of course someone has to be the first to test it after all. wink wink.


    As for multiple build/project files, DD and I seem to part ways here. He believes that there should be one system that works well that everyone can use so there's little chance of things breaking or not being up to date, which makes a lot of sense, I admit. I believe (and the way ZC was in the past was) that any developer that's willing to maintain a configuration is free to do so, as long as it doesn't break any other builds in the process (eg; cmake). Developers are really picky about their set-ups I've come to find out (myself included), and sometimes if you throw something new at them they don't like they will freak out a little bit (myself included). But the end result is that now everyone can compile the source with much less hassle so it's worth it.


    PS: I'd wager dollars to donuts the 2.50.x makefile makes it's way back into master.
    This post contains the official Gleeok™ seal of approval. Look for these and other posts in an area near you.

  3. #3
    Mad, Mad, Author ZoriaRPG's Avatar
    Join Date
    Oct 2006
    Location
    Prydon Academy
    Posts
    763
    Mentioned
    68 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    2,926
    Level
    17
    vBActivity - Bars
    Lv. Percent
    54.58%
    Daily Activity
    0%
    Weekly Activity
    10%
    Monthly Activity
    149.18%
    Quote Originally Posted by Gleeok View Post
    We've been testing cmake on all the compilers that we could so far; MSVC 2008, 2010, 2013, 2016, and gcc 5.4. This obviously doesn't necessarily mean that it works on every other platform/toolchain, but any feedback you guys could give would be very much appreciated. Of course someone has to be the first to test it after all. wink wink.


    As for multiple build/project files, DD and I seem to part ways here. He believes that there should be one system that works well that everyone can use so there's little chance of things breaking or not being up to date, which makes a lot of sense, I admit. I believe (and the way ZC was in the past was) that any developer that's willing to maintain a configuration is free to do so, as long as it doesn't break any other builds in the process (eg; cmake). Developers are really picky about their set-ups I've come to find out (myself included), and sometimes if you throw something new at them they don't like they will freak out a little bit (myself included). But the end result is that now everyone can compile the source with much less hassle so it's worth it.


    PS: I'd wager dollars to donuts the 2.50.x makefile makes it's way back into master.
    I'm on the other side of that fence, I feat. IMO, to ensure maximum participation--because all programmers are lazy--you need to provide a wide range of building formats. I also hesitate to change to anything new. I sort of want to try MSVC 2016, but that would likely kill my ability to run VC2008, as these probably cannot coexist; which on this system is barely able to run at all; so how would 2016 run?

    At least MSYS runs, and works. Until I set u a new system, I'm stuck with that.

    I would burn the old makefile in a fire. We need a new, clean makefile for this branch. One that can use the new libs, and is aware of the new objects; and had directives to do things lsuch as create ./obj/parser if it isn't there, and that uses the zcfiles/include path and zcfiles/libs paths exclusively, instead of having gcc look for libs and includes in two, or three places; which it does unless you use a command line directive to include the files.

    The bottom line is that gcc runs on everything, and uses makefiles. We need a clean makefil in this build, and we absolutely need every library, and other binary file, included in the package. Don't make people compile Allegro. Don't make them compile the sound libs, and the image libs. It's a silly waste of time, and a good way to frighten off anyone who might want to do it.

    I finally got @Dimentio up to speed with MSYS. I don't want to have to write a guide for building with CMAKE. Hell, even I don't know what instructions I need to issue to MSYS to do a cake on this without lookin at references. I rarely ever use CMAKE, although when I built Allegro, I had to resort to it.

    One thing I'll note, is that if I had all the Allero 4.4 binary files, *.a files, and libs that @DarkDraon generated, at least I could test the drawing stuff fully, before I start shifting to this branch. It's going to take a bit of time to mere all the changes, but if I had a makefile for this, it would be much faster. You see, MSYS runs as if it was a micro-emulator, so cc is horribly slow, and CMAKE is s . l. o. w. e. r. by far.

    If MSVC didn't freak out running on this system, I would in fact, just use that; but the GUI tends to freeze up, sometimes for minutes at a time, while typing.Not usable until I get newer HW. I'm pretty much stuck on the CLI + Text Editor, which to be fair, is something that I'm used to doing on Linux. I use Scintilla and MSYS on Windows; and Scintilla is extremely lightweight, so having forty source files open at one time actually works.
    @Grayswandir is used to EMacs + gcc.

    I'm also going to need to start doing OSX builds, so we'll see how that goes. The only system that I have running 10.6, is a netbook.

    Anyhow, we need the libs in the repo, and we need a plain makefile in the repo.

    I think I will try to commit some of my changes ahead of your script drawing revisions, so that if necessary, you can modify them to work with whatever you have going on with those. I know that when I tried to implement your changes, I missed somethin somewhere along the line, and while they compiled, they either didn't work, or created a flood of errors on the stack. Probably my fault, but IDK. Did you ever look at the beta that I sent to you that had them enabled? It's still on the server, if you want to see what I did, and what it was doing.

    We really need to draw a line though, and stop going back to square one. This needs to be the last time that we do that for 2.54, 2.55, 2.60. We can lay that dance again for 3.0 if you wish, but no =ore for now, please.

    I'm still waiting to hear if @Saffith signed off on this branch, as I don't want this to be another circular argument that ends us up at the beginning, again.

    It is nice to see things moving at least, and that @DarkDragon returning seemed to light some fires.


    Script Headers: RPG.zh ( v. a0.97.1 ) ( RPG.zh Thread ) | stdArguments.zh (v.6.9.9/1) | | Timers.zh (v.1.5)
    ZScript | ZC Dev | ZC 2.53 | Alucard's: stdCombos.zh (v1.1) | stdWeapons.zh | particles.z
    All of the code that I create and publish here is free for use, modification and distribution under the GPL v2.0.

  4. #4
    Administrator DarkDragon's Avatar
    Join Date
    Oct 2001
    Posts
    6,114
    Mentioned
    41 Post(s)
    Tagged
    0 Thread(s)
    vBActivity - Stats
    Points
    10,524
    Level
    30
    vBActivity - Bars
    Lv. Percent
    47.3%
    Daily Activity
    0%
    Weekly Activity
    10%
    Monthly Activity
    55.94%
    Let's separate out the issues here.

    1. There is not, and never will be, support for both Allegro 4.2 and Allegro 4.4. If you want to help with the port to Allegro 4.4, look at branch DD/alleg44. If you want to help with getting the current branch to work with MSYS first, look at the master. We have enough work on our plates without needing to maintain support for multiple versions of the Allego library, for no good reason.

    2. CMake vs many different Makefiles: Gleeok is not completely convinced, but, I have to say with all due respect, he's simply wrong . Trying to maintain multiple Makefiles in 2016 is about as crazy as "oh these version control thingies are ok, but let's keep emailing the source back and forth anyway" in 2006. Especially on a large collaborative project involving an unknown number of developers on the Internet rather than a fixed set of employees.

    Let's say I shuffle some files around, for example, I add the alleg_compat.cpp fixes that you posted to get ZC to work with Allegro 4.4. In a world where everybody is maintaining their own Makefiles, I know (since I added them) how to correctly add alleg_compat to my own Makefile (an MSVC project, in my case). Everybody else who isn't using my particular Makefile (that includes everyone using MSYS or Linux or OS X) now has a broken build. They will need to figure out how to modify their own Makefiles to correctly add the new .cpp (and of course, there is a nontrivial chance they will add it incorrectly, or in a way that is inconsistent with how I added it in the MSVC project, leading to many pleasant bugs and build issues down the line.) If the Linux developer is inactive for a few month, his Makefile might be many source file updates out of date with the current Windows Makefile. If the Linux developer is a core member of the ZC dev team, maybe they don't mind putting in the work catching up. If it's a random Linux user on the Internet, chances are they will complain here about the broken Makefile instead, or give up trying to patch ZC due to the build system "being broken."

    CMake solves these issues. If you make changes to how ZC should be built, you make them in one place and CMake automatically propagates the changes to each individual developer's toolchain and build environment. Gleeok and I get an updated MSVC project. You get an updated gcc Makefile. Etc. Of course, different environments need different build flags, etc, but the CMake file encapsulates these setting in one place, and abstracts out the parts of the build (the list of source files and how they are grouped into modules; the location of the headers; common #defines needed to get Allegro to work, etc) that are common across all platforms.

    If you want some concrete evidence, look no further than Allegro itself:
    Allegro 4.2: used a ton of different Makefiles and config scripts for different platforms
    Allegro 4.4: a single CMake file
    Allegro 5.0: a single CMake file

    For more success stories see here and an amusing (but accurate) rant about autotools vs CMake here. This blog post also makes the case for CMake. Yes, there are reasons to complain about CMake, and yes, there is some initial pain in setting up the CMake scrpts, but in the long term it solves a lot of problems once we start moving the source code around, switching library versions, etc. Developers who don't happen to use the most popular supported platform (MSVC for Gleeok and I) don't get left in the dust.

    If you want to create a private Makefile and use it, I can't stop you (other than wag my finger when something changes in the repository and breaks your Makefile, and then you come here asking for help), but please do not add random Makefiles to the official repository.

    There is already a guide for building with CMake in README.md, by the way.

    3. MSYS support: I have asked a few times already if anybody wanted MSYS support, and for help configuring the build for MSYS if so, but never heard back from you. I am still happy to do this (that goes for OS X as well). It will require a bit of one-time effort to add the correct configuration options to CMakeLists.txt, but I am willing to do the brunt of the work. Ping me on Skype tonight (I work late but will be available starting at midnight EST) for instance and I can try adding the MSYS config settings in real time.

    4. Precompiled libs in the repostory: I completely agree, but I can only compile libraries on the systems that I own (Windows 10 and Ubuntu). I am happy to add libraries for other systems, but I need those supplied to me by developers on those systems to do so.

    5. Saffith: Saffith does great work on ZC and I have an incredible amount of respect for him. While I am happy to discuss any aspect of ZC development with him at any time, he indicated he wanted to sit out this particular change and the ensuring drama, and I respect his wishes.

  5. #5
    Administrator DarkDragon's Avatar
    Join Date
    Oct 2001
    Posts
    6,114
    Mentioned
    41 Post(s)
    Tagged
    0 Thread(s)
    vBActivity - Stats
    Points
    10,524
    Level
    30
    vBActivity - Bars
    Lv. Percent
    47.3%
    Daily Activity
    0%
    Weekly Activity
    10%
    Monthly Activity
    55.94%
    I think I will try to commit some of my changes ahead of your script drawing revisions, so that if necessary, you can modify them to work with whatever you have going on with those.
    If you do this I will help merge them in, but please use the pull request system, and please send only one set of closely-related commands at a time (number of changes per patch should be ~100 lines, not ~10,000 lines).

  6. #6
    Mad, Mad, Author ZoriaRPG's Avatar
    Join Date
    Oct 2006
    Location
    Prydon Academy
    Posts
    763
    Mentioned
    68 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    2,926
    Level
    17
    vBActivity - Bars
    Lv. Percent
    54.58%
    Daily Activity
    0%
    Weekly Activity
    10%
    Monthly Activity
    149.18%
    Quote Originally Posted by DarkDragon View Post
    Let's separate out the issues here.

    1. There is not, and never will be, support for both Allegro 4.2 and Allegro 4.4. If you want to help with the port to Allegro 4.4, look at branch DD/alleg44. If you want to help with getting the current branch to work with MSYS first, look at the master. We have enough work on our plates without needing to maintain support for multiple versions of the Allego library, for no good reason.

    2. CMake vs many different Makefiles: Gleeok is not completely convinced, but, I have to say with all due respect, he's simply wrong . Trying to maintain multiple Makefiles in 2016 is about as crazy as "oh these version control thingies are ok, but let's keep emailing the source back and forth anyway" in 2006. Especially on a large collaborative project involving an unknown number of developers on the Internet rather than a fixed set of employees.

    Let's say I shuffle some files around, for example, I add the alleg_compat.cpp fixes that you posted to get ZC to work with Allegro 4.4. In a world where everybody is maintaining their own Makefiles, I know (since I added them) how to correctly add alleg_compat to my own Makefile (an MSVC project, in my case). Everybody else who isn't using my particular Makefile (that includes everyone using MSYS or Linux or OS X) now has a broken build. They will need to figure out how to modify their own Makefiles to correctly add the new .cpp (and of course, there is a nontrivial chance they will add it incorrectly, or in a way that is inconsistent with how I added it in the MSVC project, leading to many pleasant bugs and build issues down the line.) If the Linux developer is inactive for a few month, his Makefile might be many source file updates out of date with the current Windows Makefile. If the Linux developer is a core member of the ZC dev team, maybe they don't mind putting in the work catching up. If it's a random Linux user on the Internet, chances are they will complain here about the broken Makefile instead, or give up trying to patch ZC due to the build system "being broken."

    CMake solves these issues. If you make changes to how ZC should be built, you make them in one place and CMake automatically propagates the changes to each individual developer's toolchain and build environment. Gleeok and I get an updated MSVC project. You get an updated gcc Makefile. Etc. Of course, different environments need different build flags, etc, but the CMake file encapsulates these setting in one place, and abstracts out the parts of the build (the list of source files and how they are grouped into modules; the location of the headers; common #defines needed to get Allegro to work, etc) that are common across all platforms.

    If you want some concrete evidence, look no further than Allegro itself:
    Allegro 4.2: used a ton of different Makefiles and config scripts for different platforms
    Allegro 4.4: a single CMake file
    Allegro 5.0: a single CMake file

    For more success stories see here and an amusing (but accurate) rant about autotools vs CMake here. This blog post also makes the case for CMake. Yes, there are reasons to complain about CMake, and yes, there is some initial pain in setting up the CMake scrpts, but in the long term it solves a lot of problems once we start moving the source code around, switching library versions, etc. Developers who don't happen to use the most popular supported platform (MSVC for Gleeok and I) don't get left in the dust.

    If you want to create a private Makefile and use it, I can't stop you (other than wag my finger when something changes in the repository and breaks your Makefile, and then you come here asking for help), but please do not add random Makefiles to the official repository.

    There is already a guide for building with CMake in README.md, by the way.

    3. MSYS support: I have asked a few times already if anybody wanted MSYS support, and for help configuring the build for MSYS if so, but never heard back from you. I am still happy to do this (that goes for OS X as well). It will require a bit of one-time effort to add the correct configuration options to CMakeLists.txt, but I am willing to do the brunt of the work. Ping me on Skype tonight (I work late but will be available starting at midnight EST) for instance and I can try adding the MSYS config settings in real time.

    4. Precompiled libs in the repostory: I completely agree, but I can only compile libraries on the systems that I own (Windows 10 and Ubuntu). I am happy to add libraries for other systems, but I need those supplied to me by developers on those systems to do so.

    5. Saffith: Saffith does great work on ZC and I have an incredible amount of respect for him. While I am happy to discuss any aspect of ZC development with him at any time, he indicated he wanted to sit out this particular change and the ensuring drama, and I respect his wishes.
    I'm not sure what I said that would make you think that I wanted to simultaneously support ag2.4 and 4.4...? I wanted to throw ag4.4 out in a burning heap for the last 18+ months...

    I'll get with you some point this week to do the CMake/MSYS stuff. What days, or nights are best, and what time zone?


    Script Headers: RPG.zh ( v. a0.97.1 ) ( RPG.zh Thread ) | stdArguments.zh (v.6.9.9/1) | | Timers.zh (v.1.5)
    ZScript | ZC Dev | ZC 2.53 | Alucard's: stdCombos.zh (v1.1) | stdWeapons.zh | particles.z
    All of the code that I create and publish here is free for use, modification and distribution under the GPL v2.0.

  7. #7
    Administrator DarkDragon's Avatar
    Join Date
    Oct 2001
    Posts
    6,114
    Mentioned
    41 Post(s)
    Tagged
    0 Thread(s)
    vBActivity - Stats
    Points
    10,524
    Level
    30
    vBActivity - Bars
    Lv. Percent
    47.3%
    Daily Activity
    0%
    Weekly Activity
    10%
    Monthly Activity
    55.94%
    Hmm wait: you want Allegro 4.4? Or Allegro 4.2? I'd been assuming you were all for 4.4 (since you need it for some of your drawing commands) but if you're aware of some issues with 4.4 please let me know right away...

  8. #8
    Mad, Mad, Author ZoriaRPG's Avatar
    Join Date
    Oct 2006
    Location
    Prydon Academy
    Posts
    763
    Mentioned
    68 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    2,926
    Level
    17
    vBActivity - Bars
    Lv. Percent
    54.58%
    Daily Activity
    0%
    Weekly Activity
    10%
    Monthly Activity
    149.18%
    Quote Originally Posted by DarkDragon View Post
    Hmm wait: you want Allegro 4.4? Or Allegro 4.2? I'd been assuming you were all for 4.4 (since you need it for some of your drawing commands) but if you're aware of some issues with 4.4 please let me know right away...

    Clarification: 4.4.x, is desired.


    Script Headers: RPG.zh ( v. a0.97.1 ) ( RPG.zh Thread ) | stdArguments.zh (v.6.9.9/1) | | Timers.zh (v.1.5)
    ZScript | ZC Dev | ZC 2.53 | Alucard's: stdCombos.zh (v1.1) | stdWeapons.zh | particles.z
    All of the code that I create and publish here is free for use, modification and distribution under the GPL v2.0.

  9. #9
    Mad, Mad, Author ZoriaRPG's Avatar
    Join Date
    Oct 2006
    Location
    Prydon Academy
    Posts
    763
    Mentioned
    68 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    2,926
    Level
    17
    vBActivity - Bars
    Lv. Percent
    54.58%
    Daily Activity
    0%
    Weekly Activity
    10%
    Monthly Activity
    149.18%
    @DarkDragon : When you have an hour or so to spare, I have VS2008 Pro on the new Win 7 system, and VS2015 'Free' on the Win10 system. I'd like to sit down with you and get both set up to build the CMake branch, but I have never used VS2015, and I'm not sure what I need to do to build project files for VS2008 with CMake. I think I will ultimately prefer to use VS2008 though. It runs 10 to 15 times faster than 2015 for me. (CMake, is likewise installed.)

    The specs for the replacement laptop are nice though. When I was using MSYS on the old system under WIn 10, it could take anywhere from ten minutes to an hour to compile. Now it takes < 3 minutes. I think most of the problem was Win 10, not the old hardware, but I think that system is dying anyway, and the replacement is two generations newer, so this should go easier.

    Anyway... I would like to start merging this stuff, and I need to get the environment set up...
    @Gleeok might also be able to do this with me, given that he also uses VS2008, but he doesn't use any IM clients, which in this day and age...is limiting.


    Script Headers: RPG.zh ( v. a0.97.1 ) ( RPG.zh Thread ) | stdArguments.zh (v.6.9.9/1) | | Timers.zh (v.1.5)
    ZScript | ZC Dev | ZC 2.53 | Alucard's: stdCombos.zh (v1.1) | stdWeapons.zh | particles.z
    All of the code that I create and publish here is free for use, modification and distribution under the GPL v2.0.

  10. #10
    Developer ZC Developer
    Gleeok's Avatar
    Join Date
    Apr 2007
    Posts
    4,610
    Mentioned
    206 Post(s)
    Tagged
    10 Thread(s)
    vBActivity - Stats
    Points
    12,129
    Level
    32
    vBActivity - Bars
    Lv. Percent
    35.09%
    Daily Activity
    0%
    Weekly Activity
    10%
    Monthly Activity
    405.59%
    Quote Originally Posted by ZoriaRPG View Post
    @DarkDragon I think I will ultimately prefer to use VS2008 though. It runs 10 to 15 times faster than 2015 for me. (CMake, is likewise installed.)

    The specs for the replacement laptop are nice though. When I was using MSYS on the old system under WIn 10, it could take anywhere from ten minutes to an hour to compile. Now it takes < 3 minutes. I think most of the problem was Win 10, not the old hardware, but I think that system is dying anyway, and the replacement is two generations newer, so this should go easier.
    I just want take a minute to rapehammer Visual Studio (this applies to other modern crap as well). :)

    If I want to look at an .h file and double-click it: With ANY VS version > 2010 it takes 2 minutes. With 2010 it takes 20 seconds. With VS 2003 or 2008 it takes < 1 second. (2005 has a few other issues) It's so nice that a text editor has become so omnipotent that it doesn't just open up text files, but also is such amaze with .NET technology that it loads up 100 layers of super important text editing helping dlls and JITs all of them while scanning the entire HD for magic pixie dust because it knows I love to smoke magic pixie dust. So now I've gotten up and made a sandwich and got some magic pixie dust, and I try to scroll down the text file to find out it froze. It must be doing something important because I see it's using up 100% CPU on a single core, so I wait for 20 seconds for it to finish scrolling. Next I create a project and it dumps 500 MB of corrupted SQL database crap into the directory before crashing. Now's where I go do something else. The End. Now someone give me one good reason why I should run out and download VS2017???

    Windows 10 is the same; don't bother unless you are running an i7 with a fast SSE drive and have at least 16 GB of decent RAM.



    Anyway, @ZoriaRPG here are step by step build instructions for zc now:
    1)Download CMAKE
    2)Open the CMAKE gui
    3)Set the directory of zc/trunk/
    4)Click configure
    5)Select "UNITY_BUILD" (recommended for fast compile times [4x faster]) and whatever else you want (VS 2008 == vc9 tools, 2015 == vc15 tools)
    6)Click generate
    7)Open the generated MSVC project files and click build.
    8)If there are no errors then you're done!
    This post contains the official Gleeok™ seal of approval. Look for these and other posts in an area near you.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
About us
Armageddon Games is a game development group founded in 1997. We are extremely passionate about our work and our inspirations are mostly drawn from games of the 8-bit and 16-bit era.
Social