make sharedlib fails on Linux

[hendu]

Anyways hendu I hope you don't have influence over builds in Irrlicht circles, because it sounds like with your attitude, even very basic "real world" things like supporting Visual Studio .sln files wouldn't have gotten done.

Buying into proprietary tools like VS does not promote cross-platform growth either. It promotes lock-in.

Anyways go to school on how much trouble the Ogre crowd is or isn't having with their builds. Open Scene Graph is another serious 3d engine using CMake. They converted a very long time ago and are probably an example of best practices by now. Like Kitware itself, the purveyors of CMake, OSG is focused more on scientific visualization than games so they aren't your direct competition.

What do unrelated projects have to do with cmake having many issues? The issues I mean are not on the project side, but on the user side, all of them.

It makes cross-compiling practically impossible. It makes it very difficult to tweak the flags/paths for some files but not all (remember, as the end-user building, not the project creator!). It requires weird hacks into its own files to get it to properly detect GL and some other libs.
And so on. I have many more.

[bvanevery]

Buying into proprietary tools like VS does not promote cross-platform growth either. It promotes lock-in.

An open source outfit "with legs" has done the VS maintenance work for you. You don't have to and you're not locked in. CMake works, it's field proven, it's the most mature of build systems that straddle both worlds. "Cross-platform" inherently means embracing non-Unix, proprietary OSes with different cultures and toolchains than you favor. There simply aren't enough OSes out there for it to be any other way. Apple is only marginally better than Microsoft, their entire corporate paradigm is based on controlling users and straitjacketing them in walled gardens. They just have somewhat better underlying technology that looks Unixy, until you get into the core GUI value propositions of their apps. None of the console manufacturers are worth a spit, they're all about controlling developers.

Anyways go to school on how much trouble the Ogre crowd is or isn't having with their builds.

What do unrelated projects have to do with cmake having many issues? The issues I mean are not on the project side, but on the user side, all of them.

User side? Somehow I can't feel sorry for a Unix user at all, given the sheer amount of cruft any such user is expected to embrace as a matter of course. There's nothing wrong with CMake tools compared to that. In fact they've got really nice GUIs. So what kind of users are you talking about, Windows and Mac users?

It makes cross-compiling practically impossible.

I haven't tried cross-compiling with CMake. I know the capability has existed in some form or another for 5 years now, so I flat out don't believe you.

It makes it very difficult to tweak the flags/paths for some files but not all (remember, as the end-user building, not the project creator!).

And why would the typical end user want to tweak the flags and paths of some files and not all? Sounds like you're inserting your own personal issue here. To which I say, you can be responsible for learning how to modify CMakeLists.txt yourself if you require that fine a level of build control.

It requires weird hacks into its own files to get it to properly detect GL and some other libs.

That's because people at opengl.org are not motivated to actually fix those scripts in the CMake sources. I know because Kitware was going to move those bugs in the bug tracker to a backlog, after an egregiously short amount of time after they were filed, like only a couple of months. I howled, and went to both opengl.org and the specific project mailing lists for the detection scripts in question. I made my case about the value of keeping those scripts "in shape" and crickets chirped. None of those guys valued CMake enough to do anything about it, so into the backburner log they went, and crufty they remain.

Why didn't I fix them? Because, despite my willingness to point out the positives of CMake, I had a falling out with their developers many years ago, and would only do work on their behalf if some overriding need took hold. CMake is not my idea of the best build system possible. I've intended to make my own build system, but in the real world, it hasn't gotten done. opengl.org had a serious lack of open source developer energy as well, something that put me in a bit of a slough about doing anything in open source for quite a number of months. I'd try out people's example code, it wouldn't work, I'd pore over CMake scripts and file bugs, but they wouldn't fix them. So I gave up on that crowd, and swore I wouldn't waste any more time on people's shoddy builds, CMake or not.

Recently I came out of my shell, decided that I wasn't getting anything done "rolling my own" 3d engine, and should at least evaluate the extant open source offerings. I had a possible military client to spur my interest in getting something working, although I don't know that that's really going to happen. Anyways I chose to beat the Ogre, ClanLib, and Irrlicht builds into shape. Because they are all substantial projects, they are far more "on the ball" about open source development than anyone at opengl.org is. Problems get discussed and things get fixed. I still need to figure out which of these 3d engines is "worth the most" for OpenGL 3.x development on Linux.

Ogre already has a CMake build so there's no work to be done there. I'm just blocking on some OpenGL 3.x HW specific bug. ClanLib rolled their own build configuration tool for Visual Studio and uses Autoconf for Unix. It's not a tenable paradigm over the long haul, so I've had the "better build systems" discussion there as well. I would like to know if the grass is greener with Premake. It uses Lua as the scripting language. CMake had a Lua prototype at one point, but they chose not to support that, so as not to fragment their extant customer base. Annoying.

[hendu]

User side? Somehow I can't feel sorry for a Unix user at all, given the sheer amount of cruft any such user is expected to embrace as a matter of course. There's nothing wrong with CMake tools compared to that. In fact they've got really nice GUIs. So what kind of users are you talking about, Windows and Mac users?

Advanced users. The kind you want to use your project, because they tend to become developers later. The GUIs for those platforms allow even less control than the cmake cli tools.

I haven't tried cross-compiling with CMake. I know the capability has existed in some form or another for 5 years now, so I flat out don't believe you.

Try it then. "Capability exists" is a far cry from "works for most cases".

And why would the typical end user want to tweak the flags and paths of some files and not all? Sounds like you're inserting your own personal issue here. To which I say, you can be responsible for learning how to modify CMakeLists.txt yourself if you require that fine a level of build control.

Because they are an advanced user, needing to do something more than just "build it, with whatever defaults we gave". Of course these are my personal issues, how else would I have encountered them as a cmake user?

Should I list some issues I've not personally encountered instead? Not good form, IMHO.

That's because people at opengl.org are not motivated to actually fix those scripts in the CMake sources.

I need to ask: why should they? Why care about an uncommon build system of the week?

[bvanevery]

Advanced users. The kind you want to use your project, because they tend to become developers later. The GUIs for those platforms allow even less control than the cmake cli tools.

I can't take this seriously. I taught myself how to program an Atari 800 in BASIC at age 11. Back then one got things done by PEEKing and POKEing OS memory addresses. I learned Linux 0.99-something after college on my own at age 23. Now there's an internet with search engines and 1 bazillion programmers ready to rush to anyone's assistance. We never had that back in the day. As much as I am for process improvement in programmerdom, if would-be programmers can't handle the grunge, we don't need them. The CMake tool interfaces are fine. Anyone can grouse about anything they don't like, aren't familiar with, and are unwilling to exercise discipline about getting past. Or perhaps the opposite problem applies here: "I want more control" is code for "I want to make my life harder than necessary."

I haven't tried cross-compiling with CMake. I know the capability has existed in some form or another for 5 years now, so I flat out don't believe you.

Try it then. "Capability exists" is a far cry from "works for most cases".

You said "impossible" and that I certainly don't believe. In fact I don't even believe "difficult." Has warts? Sure, wouldn't blink if it did. Everything does. Do you think the GNU tools are more than polished turds, typically?

Because they are an advanced user, needing to do something more than just "build it, with whatever defaults we gave".

Then learn CMake script and stop complaining. If anyone did cater to your needs, you'd just be creating unnecessary open source work for others. Since people don't, you're basically casting aspersions on a perfectly good tool that does what it's designed to do. You're a programmer, if you want something really specific you have to program it.

Of course these are my personal issues, how else would I have encountered them as a cmake user?

If lots of people have the same feature request then it's worth taking seriously. Otherwise, if CMake's design is so impoverished, you can get on their dev mailing list and try to sell your feature request. They are responsive, but don't be surprised if they're not compelled by your individual file control issue.

That's because people at opengl.org are not motivated to actually fix those scripts in the CMake sources.

I need to ask: why should they? Why care about an uncommon build system of the week?

Because CMake is neither uncommon nor of the week. Nowadays I'd estimate it to be the 2nd system after Autoconf / Automake. Which people hate, even moreso when they need to support Visual Studio. Which is why CMake exists. That's the problem it solves. I mean, really, I might have expected these kinds of arguments with people 7 years ago, but this feels like an unproductive debate with someone who's set in his ways about the 1970s. It's a bit behind the times, to the extent that open source is including Visual Studio as a target nowadays.

Try Premake if CMake "ain't all that." It's newer and smaller. Might be cleaner.

[hendu]

You said "impossible" and that I certainly don't believe. In fact I don't even believe "difficult." Has warts? Sure, wouldn't blink if it did. Everything does. Do you think the GNU tools are more than polished turds, typically?

Please don't misquote me; I said practically impossible. I mean that it hits so many additional issues, that it becomes faster to do everything manually.

The GNU tools are better, yes. If only because they have decades of experience in handling these issues, and solutions for those cases have long been integrated. Cross-compiling using autotools is very nice in comparison to all other build systems.

Then learn CMake script and stop complaining. If anyone did cater to your needs, you'd just be creating unnecessary open source work for others. Since people don't, you're basically casting aspersions on a perfectly good tool that does what it's designed to do. You're a programmer, if you want something really specific you have to program it.

I think you're getting too defensive here. I'm not complaining that CMake sucks, or that it needs to add these features. We're discussing build systems, and since cmake lacks several features, it's completely valid discussion to mention them. It's worse for many needs than competitors. So what I do is use those competitors, instead of waste my time to make cmake suit my needs.

It's perfectly possible that it's designed to do simple builds, no cross, no customization, with VS support. If so, then it clearly succeeds at its goal. However, that is not what I want or need, or for that matter, what Irrlicht needs.

Otherwise, if CMake's design is so impoverished, you can get on their dev mailing list and try to sell your feature request.

I fail to see your point. Why would I want to improve cmake, when competitors are already better at what I need?

I mean, really, I might have expected these kinds of arguments with people 7 years ago, but this feels like an unproductive debate with someone who's set in his ways about the 1970s. It's a bit behind the times, to the extent that open source is including Visual Studio as a target nowadays.

You're trying to sell an inferior solution, using market share and a proprietary target as arguments. I happen to care about features, not market share nor supporting the lock-in of a proprietary system.

Just because our views are very different here, there's no need to constantly go ad-hominem on me. I have not once attacked your person, you have done so on mine in near every post.

[bvanevery]

It's perfectly possible that it's designed to do simple builds, no cross, no customization, with VS support. If so, then it clearly succeeds at its goal. However, that is not what I want or need, or for that matter, what Irrlicht needs.

May not be a joy to do cross-compilation with, I will accept without further debate as I have not tried it. I do question why that's a critical need for Irrlicht.

"simple builds" and "no customization" are prejudicial strawmen on your part. They have nothing to do with CMake's capabilities. For instance, what's so difficult about an Irrlicht build compared to Ogre or Open Scene Graph? Surely you can't reasonably argue that Irrlicht is larger, more complicated, or has special needs.

Irrlicht has decided that VS support is important, and only very recently. So it doesn't shock me if the implications of that haven't sunk in yet. But again, your prejudices of what matters and what doesn't, aren't appropriate for Irrlicht. If Irrlicht is going to continue to support VS, then you're going to get around to doing it better eventually.

Otherwise, if CMake's design is so impoverished, you can get on their dev mailing list and try to sell your feature request.

I fail to see your point. Why would I want to improve cmake, when competitors are already better at what I need?

I suppose you personally wouldn't. But I'm not going to let it pass that CMake is some kind of bad tool for what it's actually designed to do, just because you have your prejudices and don't think VS support is particularly important.

Just because our views are very different here, there's no need to constantly go ad-hominem on me. I have not once attacked your person, you have done so on mine in near every post.

Your argument has been premised largely on your personal needs, not what matters for a cross-platform, VS supporting project such as Irrlicht. Basically you're spreading FUD for nothing.

[hendu]

I do question why that's a critical need for Irrlicht.

Doing Windows builds from Linux has been supported for a long time now. It may be more common than you think.

If Irrlicht is going to continue to support VS, then you're going to get around to doing it better eventually.

Are you confusing me with someone else? I'm not an Irrlicht developer.

Your argument has been premised largely on your personal needs, not what matters for a cross-platform, VS supporting project such as Irrlicht. Basically you're spreading FUD for nothing.

So when I call you out on ad-hominem, you do another personal attack. I think that says enough about you.

[bvanevery]

I do question why that's a critical need for Irrlicht.

Doing Windows builds from Linux has been supported for a long time now. It may be more common than you think.

I very much doubt those builds are compiled and built against the very latest Visual Studio runtimes. I would expect them to be MinGW or Cygwin builds. I will hazard a guess that CMake can do them. I do not see it as a mission critical, dealbreaker problem if they cannot.

If Irrlicht is going to continue to support VS, then you're going to get around to doing it better eventually.

Are you confusing me with someone else? I'm not an Irrlicht developer.

And I am glad. It is only the possibility that you were an Irrlicht developer, and that I might have to persuade a recalcitrant buildmaster that does not see sense, that has kept me dealing with all of the points that you have brought up. Well, now it's all "laid bare" for anyone who needs to go up the cross-platform build learning curve.

Your argument has been premised largely on your personal needs, not what matters for a cross-platform, VS supporting project such as Irrlicht. Basically you're spreading FUD for nothing.

So when I call you out on ad-hominem, you do another personal attack. I think that says enough about you.

First off it's not an ad hominem. It's a factual statement of what you're actually doing. Your arguments about CMake mostly lack merit, and I've shown why. Irrlicht is not special compared to other 3d engines and other big projects that use CMake just fine. The entireity of KDE is driven by CMake. What do you know that they don't?

Second off, even if it were. Refrain from casting aspersions based on your personal prejudices, and less stuff will come floating back to you. I clicked on your forum profile to find out "who is this guy?" Is he someone in charge of some portion of Irrlicht development whose concerns I have to take seriously? How does he interact with people in the forums? Well, I got my answers and I will say, there's not much reason for you to be complaining about how people react to your views. You are not a big sinner, but neither are you a saint. So please, in the future less umbrage, and more objectively technically meritous argument that senior buildmasters can take seriously.

[hybrid]

Sorry to stop in here, but for now hendu has a long register of very useful and almost always on-the-point additions to Irrlicht. In just over two years. While you made it to an astonishing 24 posts with about 80% discussions about personal opinions in six years. Even though this may be no reason to stop this thread here, it could be a hint that hendu could have a much better insight into Irrlicht. So maybe just take his assumptions about Irrlicht for granted - the windows build under Linux has been used for years on the nightly build servers and also served me for a long time until I switched to Windows/VS build environment.
I'm also responsible for the Makefile and most of the structures in there. It'S basically a trade-off between minimalistic Makefile and maximal use you can get from it. After all, everything you described or want from the Makefile is somehow possible. If there's an easy way to improve this file without sacrificing any feature, we're pretty open for any patch or input from the community. Otherwise we will concentrate on more important things, which have a real benefit for the Irrlicht users.

[bvanevery]

Sorry to stop in here, but for now hendu has a long register of very useful and almost always on-the-point additions to Irrlicht. In just over two years. While you made it to an astonishing 24 posts with about 80% discussions about personal opinions in six years.

I have no present commitment to Irrlicht, as I still do not know what it can do for OpenGL 3.x. I do have abundant open source experience with cross-platform builds, both in CMake and Autoconf / Automake / GMake. I've argued some points because open source developers should be on the same page about build issues. Projects don't have to make the same decisions, but they should have equal understanding of the issues, and learn from the experience of those who have already tread the ground.

Even though this may be no reason to stop this thread here, it could be a hint that hendu could have a much better insight into Irrlicht. So maybe just take his assumptions about Irrlicht for granted - the windows build under Linux has been used for years on the nightly build servers and also served me for a long time until I switched to Windows/VS build environment.

Irrlicht isn't special in having this kind of Linux-Windows usage, nor in evolving answers to "the question" of Visual Studio. Others of us worked out these problems in open source land 7 years ago. Kitware itself, even earlier, although there were some other groups making efforts that didn't win out. To hear CMake described as "Johnny Come Lately" is... annoying.

I'm also responsible for the Makefile and most of the structures in there. It'S basically a trade-off between minimalistic Makefile and maximal use you can get from it. After all, everything you described or want from the Makefile is somehow possible. If there's an easy way to improve this file without sacrificing any feature, we're pretty open for any patch or input from the community. Otherwise we will concentrate on more important things, which have a real benefit for the Irrlicht users.

Again, different suffixes or subdirectories, but I won't be coughing it up myself until I understand what Irrlicht shader-pipeline branch can do with OpenGL 3.x. The user experience I've had out of the box is "it somewhat doesn't build." You have your own values of "what's important" as a buildmaster. Mine were, always give a newbie a clean build, lest they walk away from the project as seemingly broken.

[Nadro]

but I won't be coughing it up myself until I understand what Irrlicht shader-pipeline branch can do with OpenGL 3.x.

As I said before OGL 3.x Core Profile will be available in shader-pipeline branch in future (currently this driver isn't available in Irrlicht - just Compatibility Profile without too many features available only for DX10 hardware). Currently the most important advantage of shader-pipeline branch over a trunk is support for Flexible Vertex Format and DirectX 11.

[bvanevery]

Ok thanks... now to perform the same exercise with ClanLib and Ogre, before working on any build systems. Actually that's false. I already fixed some ClanLib Autoconf problems before even coming here, and I am resolved not to do any more such things until I understand the various 3d capabilities better.

[hendu]

I have to respond to this:

Your arguments about CMake mostly lack merit, and I've shown why.

You've refuted none of my points, instead you've repeatedly insulted me and waved your e-penis around. My person is not relevant to the argument, nor is your e-penis:

I can't take this seriously. I taught myself how to program an Atari 800 in BASIC at age 11. Back then one got things done by PEEKing and POKEing OS memory addresses. I learned Linux 0.99-something after college on my own at age 23. Now there's an internet with search engines and 1 bazillion programmers ready to rush to anyone's assistance. We never had that back in the day.

It's completely true that I have some strong opinions. Yet I somehow manage not to resort to personal attacks. It's not too much to expect, is it?

I'm out.

[bvanevery]

I can't take this seriously. I taught myself how to program an Atari 800 in BASIC at age 11. Back then one got things done by PEEKing and POKEing OS memory addresses. I learned Linux 0.99-something after college on my own at age 23. Now there's an internet with search engines and 1 bazillion programmers ready to rush to anyone's assistance. We never had that back in the day.

I'm out.

I'm not disappointed, since there isn't any point arguing CMake with you any more than I have, but for completeness I will clarify the above context. It wasn't aimed at you. It was aimed at the "advanced users who aren't yet programmers" that you thought were important to attract to a project such as Irrlicht. I am saying, they have to learn how to get their hands dirty, or they will be useless in the open source ecology. And, that using a CMake GUI is not getting one's hands dirty, much. It's a solid, easy to use, field tested interface. Like any interface, it has a learning curve. The learning curve is, frankly, pretty minimal as Unix tools go.

Still it exists, and still people do complain about having to learn stuff, or even having to install stuff. One of the historical resistances to CMake was it required actually installing CMake, as opposed to being runnable from a shell language that's already installed on a system. Basically a complaint of "well it's not Autoconf, and I should never have to do anything." That kind of whining and kvetching should be rigorously suppressed. Well, or forcible persuasion should be offered in the other direction to the degree that it can be, like when a "CMake sux" debate happens here. Sometimes one has no leverage and people will assert their right to complain, because they can. It's very hard to take installation complaints seriously on a Linux system, where packaging and repository technologies are mature, and any gizmo can be installed with a few mouseclicks from a package manager. Granted not all Unixes are Linuxes, but if they don't have a package repository infrastructure to make their lives easier, shouldn't they just convert to Linux?

[CuteAlien]

Uhm guys ... keep it technical please. Anyway - the original report (before we drifted off to build systems which is admittably mostly my fault) that different settings shouldn't use the same folder when the resulting object files are not compatible is probably a good point and something we should change. Unless something speaks against that (couldn't think of anything right now).