next »

[MorleyDev]

From what research I've down, premake4 still lacks out-of-source builds without having to specifically write the scripts to be out-of-source, official support for Visual Studio 2012 (2010 lacks a lot of C++11 niceness that I rely on heavily), a build-in build command so you don't have to explicitly invoke the tool (i.e something like cmake --build). Plus CMake has integration with the in-EAP JetBrains C++ IDE that I use.

Looking at the wiki, it seems most of the useful features like custom build commands are coming in premake5. But if I'm wrong, tell me All the documentation I can find seems to be very scattered and incomplete.

The issue I had was with getting CMake to run a 3rd party tool I wrote that is my work-in-progress C++ dependency management system. Because I'm curious what C++ is like with a cross-platform NuGet-style tool. Turns out, when you get your CMake project automatically downloading and building that project's dependencies as a build step it's a nice feeling (Tool also caches the downloaded source and compiled binaries for speedy execution, don't need a rebuild of that dependency if you've previously acquired that version of it).

[Rusk]

I've tried cmake but I found it unpleasant. Perhaps you can wrestle it to do what you want, but it just had such a bad attitude, I couldn't stand it.

Cmake: Error! Error! Incompatible libraries! Recompile!

Me: Hm, let's see. Oh, you found some other compiler. Wow, it seems this old perl installation includes its own version of gcc. How did you even find that? Here, this is the compiler I use.

Cmake: No! I am CMAKE! Do not pretend you know more about compilers than I! Libraries are INCOMPATIBLE! Recompile! Recompile everything!

Me: Oh, come on, cmake! I don't want to use some moldy old compiler you found. It has to be easier to teach you to use the right compiler, rather than recompiling every piece of code I have.

Cmake: (confident grin) No.

[Geti]

No idea what you mean by out of source builds

Unless there's some new functionality of vs 2012 solutions you need you'll be able to upgrade the solution on open just fine and get all the c++11 niceness you want.

There's no build option, that's true, but it takes all of a minute to write a script to invoke premake and follow it up with msbuild or make invocations for each platform that you want automatic builds on. We use premake as part of our toolchain on our build server, so it certainly fits into automation pipelines just fine, if not quite as easily as appending --build I think you'd need to provide more info than just build though, as you may have multiple solutions and configurations present.

One great thing if you're working in a team is that you can provide the binaries and required glue scripts for each platform via your repo and noone has to "figure out" how cmake works every time they clone the source again. Helps get new developers up and running quickly too. The binaries are only a hundred kb or so.

You're right that the docs are crap though, haha, and if you need custom build steps you'll need to wait for premake5 or write them into build automation scripts yourself, but for what it does (cross platform solution/makefile generation, nothing else) it's my go-to software.

[Sik]

I've tried cmake but I found it unpleasant. Perhaps you can wrestle it to do what you want, but it just had such a bad attitude, I couldn't stand it.

Cmake: Error! Error! Incompatible libraries! Recompile!

Me: Hm, let's see. Oh, you found some other compiler. Wow, it seems this old perl installation includes its own version of gcc. How did you even find that? Here, this is the compiler I use.

Cmake: No! I am CMAKE! Do not pretend you know more about compilers than I! Libraries are INCOMPATIBLE! Recompile! Recompile everything!

Me: Oh, come on, cmake! I don't want to use some moldy old compiler you found. It has to be easier to teach you to use the right compiler, rather than recompiling every piece of code I have.

Cmake: (confident grin) No.

Do you think that's bad? It gets worse if you're a MinGW user on Windows. It doesn't matter if you only have MinGW installed and don't have Visual Studio, CMake will always default to the latter. It catches me off guard every time, and worst part is that you can't just reinvoke CMake with the added argument, you have to first delete the entire build directory or otherwise it'll use the cached data generated from the first call and refuse to work.

[MorleyDev]

Rusk: CMake uses your path and expects a set-up that's standard, by the sounds of it that 'perl compiler' was above the actual gnu compiler on your path, so it was finding it first. You should of been able to tell it to use a different one by either removing that from the path, or setting the CXX environment variable (which is standard).

Geti: An out-of-source build is when you don't generate your build binaries or objects in the same folder as your source. It means you don't pollute the source or your git repository with any of your makefiles, solutions.. It's useful when you want to use the same source to build multiple libraries into multiple folders. Prebuild seems good for the simple set-ups, but maybe things like sbt and maven have spoiled me with what they can do. CMake seems like it's become closer to those than to Makefiles. I'd love for the syntax of prebuild, but the functionality of cmake...

Sik: "I didn't tell the program which compiler to use, so it defaulted to the default compiler for my Operating System! Whoever could of predicted this?" Okay, that one has caught me too but that's why we have "del" and "rd" on the command line. Personally I'd of just designed it so explicitly specifying the compiler you want was mandatory instead.

[Geti]

Oh, you just set the build directory to do that; we have source in trunk (svn legacy reasons), build stuff goes into build and it builds binaries into bin, with objects generated under build/obj. Works fine.

[MorleyDev]

Oh, you just set the build directory to do that; we have source in trunk (svn legacy reasons), build stuff goes into build and it builds binaries into bin, with objects generated under build/obj. Works fine.

But my point is that, as I understand it, that needs doing in the premake scripts themselves. It's one of those little things that make perhaps no difference for executables, but it makes installing a library someone else wrote more complicated. With CMake, the idea of an install is more standardised so more likely to be repeatable across multiple libraries with little modification needed by the end user.

A script could feasible download any library that uses CMake and have a reasonable chance of being able to generate and install build artefacts for any compiler without changing any more than the git/svg/mercurial repository and the cmake generator. You don't even need to customise for the build tools (make, msbuild, etc) because cmake already wraps that away via --build, --config and --target.

It's just a little easier to use for that kind of thing since it has a standardised compiler-independent workflow, I am yet to find a good way to automate prebuild libraries in as generic a manner.

[Sik]

Sik: "I didn't tell the program which compiler to use, so it defaulted to the default compiler for my Operating System! Whoever could of predicted this?" Okay, that one has caught me too but that's why we have "del" and "rd" on the command line. Personally I'd of just designed it so explicitly specifying the compiler you want was mandatory instead.

The issue is that supposedly CMake autodetects which compiler is installed if you don't tell it which one to use, but that part is obviously not working on Windows (at least not from the command line, never used the GUI frontend). If CMake can't autodetect it then it really should just make the compiler setting a requirement instead of resorting to some arbitrary default (it's not like the default is a safe value this time).

[Geti]

But my point is that, as I understand it, that needs doing in the premake scripts themselves. It's one of those little things that make perhaps no difference for executables, but it makes installing a library someone else wrote more complicated.

Do you mean that you need to tell premake that you want the objects generated elsewhere (objdir) and where to put the binaries (targetdir), or what? I don't see how you could get around that without the default option being somewhat telepathic.

If you're just talking about linking against another library, the pattern is the same as I've always encountered it - point it at a file and provide a linker option.

If you're talking about something else, please say so.



Either way CMake has always just seemed bloated and unfriendly to me, almost every time I've crossed paths with it in the context of portability it's cost me half an hour or more of me telling it what to do until it eventually spits out binaries without complaint - especially when it's been used as part of some sub-step of an installation task of some big software "thing".

(it's not like the default is a safe value this time).

Sure, but VS is more or less universally accepted as what you compile applications for on windows. It's as close as you could get to a sane default in that case, though it should probably check if it exists first :^)

[MorleyDev]

I mean with cmake, say you have a folder that contains a source (any source that can be build by CMake). Let's call it ~/some/folders/proj/source

Now, regardless of the way those cmake files are written, you can run
cmake ~/some/folders/proj/source

In any folder, any folder on your system you have access to. So I could
cd ~/series/of/other/folders && cmake ~/some/folders/proj/source

And the makefiles would be created in ~/series/of/other/folders, not ~/some/folders/proj/source. With premake, you have to actually write, in the script, location ( "build/" ). So it's not a feature of premake, but a feature of your premake script.

With premake, there has been discussion of adding a --to command line option that specifies what to treat as the root directory for generating your makefiles, to keep them out of your source code.

[Geti]

Fair enough; I tend not to build libraries from source to multiple locations if I can help it but you're right that it would be more convenient there. Is there any other use case for building to a non-predefined location or would it just be for building local copies of libraries?

[MorleyDev]

Also pretty useful if you have a building/testing pipeline that tests multiple configurations and/or compilers. You don't need to repeatedly download the source but can still do the building in parallel. And it means there's a much reduced chance any of those generated files could accidentally enter or interfere with your source control.

Actually, maybe you can help me with something. I mentioned above I'm working on a NuGet-for-C++ type thing. So at the moment it only supports CMake, and goes:
1. Get library details from ReST API
2. git clone [details->git repository url] to [Cache]/[library]/source
3. git checkout [branch] (Atm always master, gonna add support for more branches and tags)
4. In temporary directory: cmake [Cache]/[library]/source -DCMAKE_BUILD_TYPE=[Mode] -G [Generator] -DCMAKE_INSTALL_PREFIX=[Cache]/[library]/[branch]/[compiler.mode]/
5. In temporary directory: cmake --build . --config [Mode] --target install
6. Copy files from [Cache]/[library]/[branch]/[Compiler.Mode]/ to destination

Like I said, this is easy to do for almost CMake library, some support for custom CMake flags to-come-later. Is there any way this kind of 'generic' install of a library could be done premake? The actual steps needn't be the same (so naturally I'd be fine with invoking the actual tool instead of a premake --build style thing, was expecting to have to do that before I discovered --build in cmake).

Naturally some helper information could be provided by the details took from the ReST API.

[Geti]

You'd just need standardised names for your premake configurations (eg win32_debug) and to ensure each had their own object path and target path standardised to those names (then just trigger all your builds); at least for installs where the only thing to be installed is the binary -  for more complicated installs you could have scripts parametised on the configuration name to complete the install, but you'd need some way for those to be cross platform to avoid wasting time rewriting them for each OS.

 If you want to build in parallel, for some build environments you might need to make unique copies of the solution generated (eg I don't think vs likes you opening a solution in 2 places, though maybe you can tell the cli tools you don't care).

fwiw it's normal and expected to set an object directory in premake and not just build your objects in the same directory as source, I don't know anyone that prefers to do that outside of tiny projects with one or two source files

[makerimages]

I'm grumpy, because

Code:

 public  Vector2f[] calculateUVMapping(int texture, int atlasWidth, int atlasHeight) {
        int textureIndex = texture;

        int u = textureIndex % atlasWidth;
        int v = textureIndex / atlasHeight;

        float xOffset = 1f / atlasWidth;
        float yOffset = 1f / atlasHeight;

        float uOffset = (u * xOffset);
        float vOffset = (v * yOffset);

        Vector2f[] UVList = new Vector2f[4];

        UVList[0] = new Vector2f(uOffset, vOffset); // 0,0
        UVList[1] = new Vector2f(uOffset, vOffset + yOffset); // 0,1
        UVList[2] = new Vector2f(uOffset + xOffset, vOffset); // 1,0
        UVList[3] = new Vector2f(uOffset + xOffset, vOffset + yOffset); // 1,1

        return UVList;
    }

will load a texture from an atlas, but the texture has a diagonal black line trough it...

[Will Vale]

FWIW the premake5 in premake-dev has been pretty stable for me, and it's easy to build from source. So if you need a feature which isn't in the release yet but does exist in 5 it might be worth trying out.

It's also pretty easy to extend.

Will

[Quarry]

I'm grumpy, because

Code:

 public  Vector2f[] calculateUVMapping(int texture, int atlasWidth, int atlasHeight) {
        int textureIndex = texture;

        int u = textureIndex % atlasWidth;
        int v = textureIndex / atlasHeight;

        float xOffset = 1f / atlasWidth;
        float yOffset = 1f / atlasHeight;

        float uOffset = (u * xOffset);
        float vOffset = (v * yOffset);

        Vector2f[] UVList = new Vector2f[4];

        UVList[0] = new Vector2f(uOffset, vOffset); // 0,0
        UVList[1] = new Vector2f(uOffset, vOffset + yOffset); // 0,1
        UVList[2] = new Vector2f(uOffset + xOffset, vOffset); // 1,0
        UVList[3] = new Vector2f(uOffset + xOffset, vOffset + yOffset); // 1,1

        return UVList;
    }

will load a texture from an atlas, but the texture has a diagonal black line trough it...

This may be because of vertices not touching each other diagonally

[makerimages]

Negative, the lines 2 and 3 were swapped in the array, now works fine... trust the stackexchange code my a**... Figured it out when I read the comments on the lines and went: "Wait aminute... one does not make quads in that orientation..."

[standardcombo]

In C#, if a struct cannot equal null, what is supposed to happen when you cast an object of 'object' type to a struct?

class MyClass {}
struct MyStruct {}

object obj = new MyClass();

MyStruct s = (MyStruct)obj; <------- ?

[Sik]

Trying to run CMake to crosscompile PhysicsFS, I get an error. Trying to run CMake again with just the -? parameter (literally just "show usage"), and still I get the error. Looks like CMake broke horribly, and reinstalling it isn't helping. Ugh.

Code:

sik@host221:~$ cmake -?
Inconsistency detected by ld.so: dl-version.c: 224: _dl_check_map_versions: Assertion `needed != ((void *)0)' failed!

¯\(º_o)/¯ Most annoying thing is that it was working before, and this doesn't just prevent me from crosscompiling, it also prevents me from updating PhysicsFS if a new version comes out (since I can't rebuild it anymore). Does anybody know what's up?

[Geti]

That error is because CMake's missing libraries that were meant to be added at link time, but weren't, and so fail upon runtime linking.
It's happened to people before here, which might have your solution.

Negative, the lines 2 and 3 were swapped in the array, now works fine... trust the stackexchange code my a**... Figured it out when I read the comments on the lines and went: "Wait aminute... one does not make quads in that orientation..."

The copypaste-code demons strike again