tutorial building for "Learning Modern 3D Graphics

Hi, sorry if i hijack this thread but my problem is identical: i fail to compile, build and run examples from the tutorial. Here is what i have:

uname -a
Linux faeton 3.0.0-14-generic #23-Ubuntu SMP Mon Nov 21 20:34:47 UTC 2011 i686 i686 i386 GNU/Linux

i download and extract both Tutorial 0.3.7 and premake-4.3 then carry out this sequence of actions:
go to glsdk subfolder in Tutorial and run

../../premake-4.3/bin/release/premake4 codeblocks

then go to the tinyxml folder and run the same

../../premake-4.3/bin/release/premake4 codeblocks

then go to Test and, guess what :), run

../../premake-4.3/bin/release/premake4 codeblocks

and run

codeblocks Test.workspace

then try to compile the Test project and get


||=== Test, Debug ===|
ld||cannot find -lglloadD|
ld||cannot find -lglimgD|
ld||cannot find -lglutilD|
ld||cannot find -lglmeshD|
ld||cannot find -lfreeglutD|
ld||cannot find -ltinyxml_pmD|
||=== Build finished: 6 errors, 0 warnings ===|

compiling the framework project succeeds but running it results in

You must select a host application to "run" a library...

i also tried

sudo ldconfig

which didn’t help (and i’m not sure if it was supposed to - i do sometimes fire sudo commands i don’t really understand)

this is my k-th attempt to get the whole thing working and i did have some luck a couple of days ago by trying to compile the contents of Tut 01 Hello Triangle: i got “undefined __gle” something compilation errors but i can’t replay them now - i don’t remember what i did to get them.

Tyro1: Please take note on how to explain your problem. All3fox has clearly explained all of the steps he has done, and the errors in what he did are plainly evident. This allows me to effectively help him, rather than having to constantly ask him “what are you doing, what errors are you getting, etc.”

then go to Test and, guess what :), run

Test is not for you :wink: I will be deleting that directory from future releases. Yes, I know there’s a Premake script in there and everything, but it’s for testing purposes, not user purposes.

Note that the instructions don’t mention the Test directory. Please try to follow the instructions more closely in the future.

and run

codeblocks Test.workspace

You skipped some steps. Remember: Premake4 doesn’t actually make anything. All it does is generate build files. You still have to use the build files it generates to build that project.

After each execution of Premake4, you are supposed to use your build tools (Code::Blocks in this case) to build the project generated by it. So when you did:


cd //glsdk directory
../../premake-4.3/bin/release/premake4 codeblocks

It should have been followed by:


codeblocks glsdk.workspace

You build that project, in both debug and release. Only after this step is complete do you go on to build TinyXML. And again, you must load the TinyXML workspace after using Premake, and again you must build it in debug and release.

Once that’s done, you’re ready to build the tutorials.

Thanks! It nearly worked: i did as you said but when compiling freeglut project in glsdk workspace i got (sorry for partially russian)

||=== freeglut, Debug ===|
/Tutorial 0.3.7/glsdk/freeglut/src/freeglut_joystick.c|1430|ошибка: «O_RDONLY» undeclared (first use in this function)|
/Tutorial 0.3.7/glsdk/freeglut/src/freeglut_joystick.c|1430|замечание: each undeclared identifier is reported only once for each function it appears in|
/Tutorial 0.3.7/glsdk/freeglut/src/freeglut_joystick.c|1448|ошибка: «F_SETFL» undeclared (first use in this function)|
/Tutorial 0.3.7/glsdk/freeglut/src/freeglut_joystick.c|1448|ошибка: «O_NONBLOCK» undeclared (first use in this function)|
/Tutorial 0.3.7/glsdk/freeglut/src/freeglut_joystick.c|1597|ошибка: «F_OK» undeclared (first use in this function)|
||=== Build finished: 5 errors, 0 warnings ===|

however now when compiling Tut 01 Main in Tutorial1.workspace i get just one single (and expected due to above failure) mistake

||=== Tut 01 Main, Debug ===|
ld||cannot find -lfreeglutD|
||=== Build finished: 1 errors, 0 warnings ===|

perhaps you know how to deal with this either? thanks in advance. (the reduced amount of mistakes indicates i’ve carried out your instructions correctly, right?)

It looks like this is something specific to Linux/Ubuntu with Code::Blocks and FreeGLUT.

How exactly did you get Code::Blocks installed on Ubuntu? I haven’t managed to find a way to do that, so I’ve only been able to test the Code::Blocks build on Windows with MingW.

Until I can troubleshoot it, you may want to try using a regular makefile for the SDK rather than Code::Blocks. So use Premake4 gmake to create the makefile for the SDK, and then use make config=... to build Debug or Release.

the reduced amount of mistakes indicates i’ve carried out your instructions correctly, right?

You’re doing everything correctly at this point.

Code::Blocks is a popular and large enough project that I’d expect Ubuntu to have packages for it - perhaps in a add-on package repository?

F_SETFL should be provided by fcntl.h (for me it is in /usr/include/bits/fcntl.h which is included by /usr/include/fcntl.h). On my system the package glibc-headers provides these files (on Fedora 16), Ubuntu probably has a similarly named package that provides system headers.

all3fox: Did you post the complete compiler output, specifically: is there no message about a file not being found?

How exactly did you get Code::Blocks installed on Ubuntu?

that was either

sudo apt-get install codeblocks

or (but i strongly doubt it) compiling from source.

i seem to have found the place in the manual

For GNU and makefile-based builds, this is “gmake”. This will generate a makefile. To build for debug, use make config=debug; similarly, to build for release, use make config=release.

Using the generated build files, compile for both debug and release. You should build the entire solution; the tutorials use all of the libraries provided.

but going to sleep now (it’s past midnight already). Huge thanks for help!

Need a little help in here: industriousone.com/premake doesn’t respond to me


all3fox@faeton:~$ ping industriousone.com
PING industriousone.com (204.11.246.1) 56(84) bytes of data.
^C
--- industriousone.com ping statistics ---
8 packets transmitted, 0 received, 100% packet loss, time 7054ms
all3fox@faeton:~$ 

while isup.me says it’s down just for me. So could anyone please download premake4-3 for me (Ubuntu) and share it via something? I decided to make a clean attempt once again because compiling with gmake results in:


all3fox@faeton:~/Tutorial 0.3.7/glsdk$ ../../premake-4.3/bin/release/premake4 gmake
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
/bin/bash: /home/all3fox/Tutorial: No such file or directory
configure: WARNING: `missing' script is too old or missing
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables... 
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking whether gcc and cc understand -c and -o together... yes
checking for an ANSI C-conforming const... yes
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking for a sed that does not truncate output... /bin/sed
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for /usr/bin/ld option to reload object files... -r
checking for BSD-compatible nm... /usr/bin/nm -B
checking whether ln -s works... yes
checking how to recognize dependent libraries... pass_all
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking dlfcn.h usability... yes
checking dlfcn.h presence... yes
checking for dlfcn.h... yes
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... gcc3
checking how to run the C++ preprocessor... g++ -E
checking for g77... no
checking for xlf... no
checking for f77... no
checking for frt... no
checking for pgf77... no
checking for cf77... no
checking for fort77... no
checking for fl32... no
checking for af77... no
checking for xlf90... no
checking for f90... no
checking for pgf90... no
checking for pghpf... no
checking for epcf90... no
checking for gfortran... no
checking for g95... no
checking for xlf95... no
checking for f95... no
checking for fort... no
checking for ifort... no
checking for ifc... no
checking for efc... no
checking for pgf95... no
checking for lf95... no
checking for ftn... no
checking whether we are using the GNU Fortran 77 compiler... no
checking whether  accepts -g... no
checking the maximum length of command line arguments... 1572864
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for objdir... .libs
checking for ar... ar
checking for ranlib... ranlib
checking for strip... strip
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC
checking if gcc PIC flag -fPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking for shl_load... no
checking for shl_load in -ldld... no
checking for dlopen... no
checking for dlopen in -ldl... yes
checking whether a program can dlopen itself... yes
checking whether a statically linked program can dlopen itself... no
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
configure: creating libtool
appending configuration tag "CXX" to libtool
checking for ld used by g++... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes
checking for g++ option to produce PIC... -fPIC
checking if g++ PIC flag -fPIC works... yes
checking if g++ static flag -static works... yes
checking if g++ supports -c -o file.o... yes
checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes
checking dynamic linker characteristics... GNU/Linux ld.so
(cached) (cached) checking how to hardcode library paths into programs... immediate
appending configuration tag "F77" to libtool
checking for X... libraries , headers 
checking for gethostbyname... yes
checking for connect... yes
checking for remove... yes
checking for shmat... yes
checking for IceConnectionNumber in -lICE... yes
checking for XF86VidModeSwitchToMode in -lXxf86vm... no
checking for ANSI C header files... (cached) yes
checking GL/gl.h usability... yes
checking GL/gl.h presence... yes
checking for GL/gl.h... yes
checking GL/glu.h usability... yes
checking GL/glu.h presence... yes
checking for GL/glu.h... yes
checking GL/glx.h usability... yes
checking GL/glx.h presence... yes
checking for GL/glx.h... yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking limits.h usability... yes
checking limits.h presence... yes
checking for limits.h... yes
checking sys/ioctl.h usability... yes
checking sys/ioctl.h presence... yes
checking for sys/ioctl.h... yes
checking sys/param.h usability... yes
checking sys/param.h presence... yes
checking for sys/param.h... yes
checking sys/time.h usability... yes
checking sys/time.h presence... yes
checking for sys/time.h... yes
checking whether time.h and sys/time.h may both be included... yes
checking for X11/extensions/xf86vmode.h... no
checking X11/extensions/XI.h usability... yes
checking X11/extensions/XI.h presence... yes
checking for X11/extensions/XI.h... yes
checking X11/extensions/XInput.h usability... yes
checking X11/extensions/XInput.h presence... yes
checking for X11/extensions/XInput.h... yes
checking whether gcc needs -traditional... no
checking for vprintf... yes
checking for _doprnt... no
checking for cos in -lm... yes
checking for gettimeofday... yes
configure: creating ./config.status
config.status: creating Makefile
config.status: creating doc/Makefile
config.status: creating include/GL/Makefile
config.status: creating include/Makefile
config.status: creating progs/Makefile
config.status: creating progs/demos/CallbackMaker/Makefile
config.status: creating progs/demos/Fractals/Makefile
config.status: creating progs/demos/Fractals_random/Makefile
config.status: creating progs/demos/Lorenz/Makefile
config.status: creating progs/demos/Makefile
config.status: creating progs/demos/One/Makefile
config.status: creating progs/demos/shapes/Makefile
config.status: creating progs/demos/smooth_opengl3/Makefile
config.status: creating progs/demos/spaceball/Makefile
config.status: creating src/Makefile
config.status: creating config.h
config.status: config.h is unchanged
config.status: executing depfiles commands
Building configurations...
Running action 'gmake'...
Generating Makefile...
Generating glload/Makefile...
Generating glimg/Makefile...
Generating freeglut/Makefile...
Generating glutil/Makefile...
Generating glmesh/Makefile...
Done.
all3fox@faeton:~/Tutorial 0.3.7/glsdk$ make config=debug
==== Building glload (debug) ====
==== Building glimg (debug) ====
==== Building freeglut (debug) ====
==== Building glutil (debug) ====
==== Building glmesh (debug) ====
all3fox@faeton:~/Tutorial 0.3.7/glsdk$ make config=release
==== Building glload (release) ====
==== Building glimg (release) ====
==== Building freeglut (release) ====
==== Building glutil (release) ====
==== Building glmesh (release) ====
all3fox@faeton:~/Tutorial 0.3.7/glsdk$ cd ..
all3fox@faeton:~/Tutorial 0.3.7$ cd tinyxml/
all3fox@faeton:~/Tutorial 0.3.7/tinyxml$ ../../premake-4.3/bin/release/premake4 gmake
Building configurations...
Running action 'gmake'...
Generating Makefile...
Generating tinyxml_pm.make...
Done.
all3fox@faeton:~/Tutorial 0.3.7/tinyxml$ make config=debug
==== Building tinyxml_pm (debug) ====
all3fox@faeton:~/Tutorial 0.3.7/tinyxml$ make config=release
==== Building tinyxml_pm (release) ====
all3fox@faeton:~/Tutorial 0.3.7/tinyxml$ cd ..
all3fox@faeton:~/Tutorial 0.3.7$ cd Tut\ 01\ Hello\ Triangle/
all3fox@faeton:~/Tutorial 0.3.7/Tut 01 Hello Triangle$ ../../premake-4.3/bin/release/premake4 gmake
Building configurations...
Running action 'gmake'...
Generating Makefile...
Generating ../framework/Makefile...
Generating Tut 01 Main.make...
Done.
all3fox@faeton:~/Tutorial 0.3.7/Tut 01 Hello Triangle$ make config=debug
==== Building framework (debug) ====
==== Building Tut 01 Main (debug) ====
all3fox@faeton:~/Tutorial 0.3.7/Tut 01 Hello Triangle$ make config=release
==== Building framework (release) ====
==== Building Tut 01 Main (release) ====
all3fox@faeton:~/Tutorial 0.3.7/Tut 01 Hello Triangle$ ./Tut\ 01\ Main
freeglut (./Tut 01 Main): glXCreateContextAttribsARB not found
all3fox@faeton:~/Tutorial 0.3.7/Tut 01 Hello Triangle$ ./Tut\ 01\ MainD
freeglut (./Tut 01 MainD): glXCreateContextAttribsARB not found

And if i’m doing something wrong again, please tell me. The current mistakes i get are trigured by the last two commands above.

UPD i scanned this forum and as far as i understand it’s worth mentioning that i’m running on ASUS K40IJ notebook with Intel graphics which has kinda bad support for openGL, right?

i scanned this forum and as far as i understand it’s worth mentioning that i’m running on ASUS K40IJ notebook with Intel graphics which has kinda bad support for openGL, right?

Yeah, it looks like Intel didn’t attempt to implement GL 3.0 with your integrated chipset (even though they support D3D10). And these tutorials require GL 3.3 to run.

Sorry about that.

thanks a bundle, going to revive my decent desktop machine first.

ok, so i revived my desktop which is
Intel Core 2 Duo smth + motherboard ASUS P5QE + ATI Radeon HD 4870 (with an installed proprietary driver that has OpenGL 3.3.11318 Compatibility Profile Context)
and is now running a completely clear Ubuntu

all3fox@aldan:$ uname -a
Linux aldan 3.0.0-14-generic #23-Ubuntu SMP Mon Nov 21 20:28:43 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux

so i get Tutorial 0.3.7 and premake4 and make my first attempts to compile in glsdk subdirectory. These attempts fail because of several consequent codeblocks compilation errors (for some i found solutions):

  1. Xlib.h no such file or directory
sudo apt-get install libx11-dev
  1. GL/glu.h No such file or directory
sudo apt-get install libglu1-mesa-dev
  1. this error actually bugged me: codeblocks said “/bin/sh: g++ not found”
sudo apt-get install g++
  1. XInput.h no such file or directory
sudo apt-get install libxi-dev

and then i hit the fifth error that i had already encountered before:


||=== freeglut, Debug ===|
/Tutorial 0.3.7/glsdk/freeglut/src/freeglut_joystick.c|1430|ошибка: «O_RDONLY» undeclared (first use in this function)|
/Tutorial 0.3.7/glsdk/freeglut/src/freeglut_joystick.c|1430|замечание: each undeclared identifier is reported only once for each function it appears in|
/Tutorial 0.3.7/glsdk/freeglut/src/freeglut_joystick.c|1448|ошибка: «F_SETFL» undeclared (first use in this function)|
/Tutorial 0.3.7/glsdk/freeglut/src/freeglut_joystick.c|1448|ошибка: «O_NONBLOCK» undeclared (first use in this function)|
/Tutorial 0.3.7/glsdk/freeglut/src/freeglut_joystick.c|1597|ошибка: «F_OK» undeclared (first use in this function)|
||=== Build finished: 5 errors, 0 warnings ===|

i googled it more aggresively than before but the only decent thing i found was that guys from some other project encountered it a year or so ago and their solution, as far as i understood, was to throw the freeglu_joystick.c out from freeglut.
here is their debating http://code.google.com/p/box2d/issues/detail?id=77#c10
i’d be happy to hear any explanations for this but meanwhile i’ll try to compile it with gmake.

great news (at least for me) - after compiling for gmake and running the Tut 01 Hello Triangle i finally see this bloody white triangle on black font. Thanks to everyone :slight_smile: Can finally start reading about OpenGL now.

all3fox: Did you post the complete compiler output, specifically: is there no message about a file not being found?

sorry i didn’t notice that question at night. Yes, it was the complete output from codeblocks. No “file not found” or other messages.

Hi again. In another thread you emphasized ease of use for your SDK. The above is why people typically ship binaries in a SDK. So that people with no deep investment in figuring out how to use stuff, can understand the essentials of what is offered without having to deal with build issues. Once people have made it past that point and decided a SDK is “worth it,” of course the build should be easy to do, so long as one is willing to understand Premake etc.

Another reason for shipping binaries, is it proves that the SDK was buildable, at least at some moment in time. If binaries are released frequently, then it’s proven at a recent moment in time.

I don’t see how that would help in this case, since virtually no Linux-based library ships binaries. This is primarily because Linux binaries don’t work very well on different machines. Even within the same distro, different machines will have different libraries and such installed.

When you’re shipping something for a single platform like Windows, it’s theoretically possible to ship binaries. When you’re dealing with being multi-platform, it’s simply untenable. On Linux, the most effective way to ship someone a library is as source code and let them build it themselves. Even on Windows it’s non-trivial, as you need library variants for different compilers and such.

More importantly, this is a tutorial, not an SDK. The SDK is just used by the tutorial. And the build is less complex than it was before the SDK.

I’m not a Linuxer, I tend to try it every few years and run away. But your comment doesn’t make sense to me, because I know there are distros, and people use them. People don’t just spend all day rebuilding distros, unless they’re serious tweakers who’ve just got to get that last optimization flag in there. So packages abound. Packaging on Linux is very modern compared to open source on Windows, where it’s a joke (not counting Cygwin). Since I don’t quite believe you, but I’m not really sure, I guess I’ll go look for counterexamples of common libraries that have Linux packaging. Or even Linuxy ideas about SDKs. EDIT: Ok right didn’t believe you. :slight_smile: Ogre 1.7.3 SDK has a prebuilt Ubuntu package, research concluded.

Even on Windows it’s non-trivial, as you need library variants for different compilers and such.

This I can speak to, because Windows is the primary open source drill I’ve done. Yes the work is non-trivial, but that’s why a good SDK does the work, so that the consumers benefit and don’t have to do it themselves.

More importantly, this is a tutorial, not an SDK. The SDK is just used by the tutorial. And the build is less complex than it was before the SDK.

Well admittedly I did not read the whole thread. I was just searching for all of your posts about glload to understand your SDK objectives. Half of the thread seemed pertinent enough, so I replied.

As for making a tutorial, I don’t think the point is lost, however. Are you trying to teach OpenGL? Or are you trying to teach build systems? If the former and not the latter, it would be better to ship binaries and generated project files. My meager understanding is that premake4 can do that. You get standalone project files out the other end. Whereas the end results from CMake still have CMake as a final component.

Come on, Brandon J. Van Every, don’t be that in love with shipping things in binary! Looking back on the build instructions for this particular tutorial i realize that everything was in its’ rightful place so that to make the building process less painful. The fact that i kept failing meant only my lack of experience in building stuff which also means that i’ve learnt something.

Are you trying to teach OpenGL? Or are you trying to teach build systems?

both, sure. And that’s a huge plus not a minus as you try to convince us. A plus because everything is decently documented.

I suppose it’s good that you value a learning curve, but many people don’t. Either because they have too little experience, or they have too much experience. If you want the maximum uptake for something, make it as easy as possible for people to get going.

Ogre 1.7.3 SDK has a prebuilt Ubuntu package, research concluded.

That certainly is a package. But I don’t see the “prebuilt” part. As I understand it, PPAs for libraries are perfectly capable of doing the building as part of the install process.

Also, Ogre isn’t a tutorial; it’s an SDK. You need to be able to build tutorials, because you will want to play with the example code. Thus, shipping a build process with full source code is very important.

As for making a tutorial, I don’t think the point is lost, however. Are you trying to teach OpenGL? Or are you trying to teach build systems? If the former and not the latter, it would be better to ship binaries and generated project files.

A tutorial is not a series of programs that you run to see cool stuff. That’s called a demo or example code. That’s what you get from here (no offense intended; example code is important, for the purpose that it serves). Tutorials exist to do something very different. The most important parts of a tutorial are, in this order:

1: The text that explains how it works. Without this, actually learning why the particular code is where it is becomes virtually impossible.

2: The code that implements it. The salient points are covered in the text, but it’s always nice to see the full code example.

3: The compiled binaries that show what the tutorial does. Without this… well, you could look at the pictures embedded in the text of the tutorial and follow along with little problem.

In short, the need to actually run the code is a distant third on the scale of “what actually matters for learning.” Sure, you need to be able to build the projects to do the exercises at the end of the chapters. But in terms of following the tutorial itself? Not the most important thing in the world.

Does Premake4 allow you to ship build files? Sure. But the whole point of it is that you don’t have to. They can make the build files for their particular build system with a single command line. If someone still uses VC6, they can get their project files. If someone uses Code::Blocks, they can get their workspaces. If someone loves Make, they can get makefiles.

Here is a list of the possible combination of OS and build files that I support by shipping a simple Premake4 script:

1: VC6
2: VC2002
3: VC2003
4: VC2005
5: VC2008
6: VC2010
7: Windows Make via Cygwin
8: Windows Make via MingW
9: Windows Code::Blocks
10: Windows CodeLite
11: Linus Make
12: Linux Code::Blocks
13: Linux CodeLite

That’s thirteen separate build options. And since many of these use the same filenames, I would have to generate these into separate directories, thus creating 13 separate directories for each of the (currently 16) tutorials, the SDK, and TinyXML. That’s a lot of clutter to look though, especially since each user is only going to be looking for their particular build tool.

Or I can just ask the user to type a simple command-line. A process that I take time out in the text to actually explain. This is not a Herculean effort requiring god-like strength. It’s “premake4 platform”, where platform is well-defined by a direct link to the Premake documentation. That’s how Premake is intended to work.

That’s the thing: we are not talking about an onerous process. We’re not talking about forcing people to have to cobble together a build from loose files and some overly-simplistic directions (see the Lua distro if you want to see a really crappy build process). We’re talking about one command. Execute it once, and you get your build files.

There are levels to “ease of use”. Currently, I would say the tutorials and the SDK are “reasonably easy”. I simply do not feel that attaining the level of “ease of use” you’re talking about is worth the time, effort, or the problems that come along with it (large downloads. Shipping 10 separate windows binaries for 45+ executables in debug and release isn’t small. Not to mention DLL-hell, since you keep wanting those).

If you follow the link to the Ubuntu package that’s on that Ogre SDK page, you will see a nice text that says

Contains prebuilt Ubuntu packages for the Ogre library and its components (http://www.ogre3d.org).

To install the dev libraries, type:
> sudo apt-get install libogre-dev

I took that comment at face value. I don’t know if it’s true. I’m not a Linuxer, you can go test it. Even if it isn’t prebuilt, it’s claiming that you invoke one apt command and you’re done. That’s how things should be. No work, you’re a build system, do it for me.

In short, the need to actually run the code is a distant third on the scale of “what actually matters for learning.”

Only you say so. Everyone else wants to know that their learning curve isn’t going to be a pointless waste of time. Clicking on a prebuilt binary sets a goal: this is what you’re aiming to complete.

Does Premake4 allow you to ship build files? Sure. But the whole point of it is that you don’t have to.

No, that’s not the whole point. The point is you can make one build description that’s cross-platform, cross-IDE, written in a sane language, and produces standalone build files. Actually, “the point” doesn’t have to include all of that. I’m mainly interested in the sane language, I’m not going to learn MSBuild. If you don’t want to ship binaries that’s your point, not “the whole” point.

If someone still uses VC6,

then maybe they should be in a nursing home. :slight_smile: Ok ok, maybe part of the Space Shuttle runs on VC6. Wait, they retired those. Ok! Some part of someone’s ancient OpenGL infrastructure somewhere actually runs on VC6, and it’s crucial to national security. I’m sure someone does it but it’s not what I’d call an important case use.

That’s thirteen separate build options.

Welcome to build engineering. :wink: It’s a good practice to support all the ones that are mainstream. Do you want to talk about automated nightly builds and test suites?

That’s a lot of clutter to look though,

The world manages. Go look at some of the bigger CMake driven open source projects.

Or I can just ask the user to type a simple command-line. A process that I take time out in the text to actually explain.

I think one verdict on that was had at the beginning of this thread. You “solved” the problem by insisting that someone RTFM. He got angry. Regardless of the ethics or morality of it, it says to me your approach is not as simple as you claim.

Look all we’re actually arguing about at this point is how much work you personally care to do. Your gruntwork vs. how much you want people to utilize your SDK. If you want maximal adoption, you can adopt the practices that the largest, most popular cross-platform open source projects use.

Only you say so. Everyone else wants to know that their learning curve isn’t going to be a pointless waste of time. Clicking on a prebuilt binary sets a goal: this is what you’re aiming to complete.

Yeah, I guess you’re right. I mean, I’m obviously a fool for spending all that time writing over three hundred pages of text, spending hours making charts and diagrams to explain points. Editing passages to make sure they’re clear to a new user. Rearranging text so that each topic flows properly into the next, so that each tutorial builds on and properly reinforces its predecessors. That was a complete waste of time for a project intended for someone to learn from.

I mean, who needs detailed explanations for things when you can just ship binaries? I mean screw that whole teaching people how to use shader-based OpenGL; we’ve got to get some friggin’ binaries out to people!

Oh, and if you’re saying that you were talking about my SDK and not the tutorial, don’t bother. You clearly said, “As for making a tutorial, I don’t think the point is lost, however. Are you trying to teach OpenGL? Or are you trying to teach build systems? If the former and not the latter, it would be better to ship binaries and generated project files.” And my point was that building the code is not the most important thing for learning with my tutorials.

No, that’s not the whole point. The point is you can make one build description that’s cross-platform, cross-IDE, written in a sane language, and produces standalone build files. Actually, “the point” doesn’t have to include all of that. I’m mainly interested in the sane language, I’m not going to learn MSBuild. If you don’t want to ship binaries that’s your point, not “the whole” point.

Similarly, your interest in “the sane language” is also not “the whole point”. It’s a good point, but only using Premake4 because it’s a nice build language misses a lot of its utility.

I use Premake4 as a way to support build systems that I have neither the time nor inclination to use. That’s the whole point for my projects. It’s a clean way to allow the user to pick their favorite build tool.

We have different needs. That’s fine. What makes your needs so much better than mine?

then maybe they should be in a nursing home. smile Ok ok, maybe part of the Space Shuttle runs on VC6. Wait, they retired those. Ok! Some part of someone’s ancient OpenGL infrastructure somewhere actually runs on VC6, and it’s crucial to national security. I’m sure someone does it but it’s not what I’d call an important case use.

And that’s the whole point. You believe that VC6 users are not “an important case use”.

I don’t agree. The thing I hate the absolute most when working with Open Source projects is being told what build system to use. I hate projects that don’t come with Visual Studio builds (or something that can generate them, like CMake/Premake). I hate the arrogance of OSD people who think that Make is all everyone should use, and screw those Windows developers for their fancy IDEs; just use VI like everyone else.

I don’t use VC6. And I don’t think that people should. But I do not believe it is my right to tell them that they shouldn’t. I will make no special effort to ensure my code compiles on VC6; it is not officially supported. But I will also make no special effort to stop them.

If someone hates VC7+, who am I to say that they’re wrong? Who am I to say that they shouldn’t have a build system where they use VC6 as their IDE (and therefore need VC6 project files), but they actually hook into VC2010’s compiler via various means? I may not use VC6, but I will not deliberately hurt them if I can avoid it.

Yes, I don’t support every possible IDE. But I do use Premake4, which supports a hefty number of builds. That is, as far as I’m concerned, doing diligence as far as supporting builds.

I will make my projects available according to the values to which I hold. I believe that a project should be self-contained, affecting as little as possible on a user’s system. I believe that a project should have a build system that accommodates the user’s preferred tool path as much as possible, not tell them how to build their stuff. And yes, I believe that the build system should be reasonable straightforward and centralized as much as possible. Premake4 offers that.

I think one verdict on that was had at the beginning of this thread. You “solved” the problem by insisting that someone RTFM. He got angry. Regardless of the ethics or morality of it, it says to me your approach is not as simple as you claim.

That is not a reasonable conclusion given the available evidence. This thread contains exactly three people who ran into a problem. Two of them were easily and quickly helped. One of them could not be helped because he refused to actually say what the problem was in a reasonable way.

The only way to know whether the process is “as simple as (I) claim” is to match the number of build failures to the number of successes. Since neither of us has any particular knowledge of how many build successes I’ve had (I can give you download stats of around a thousand or so for the SDK, and half that for any given version of the tutorials. But a download does not necessarily mean a success), any attempt at a factual statement one way or another is false.

Trust me: people like tyro1 exist. And they will have problems with the simplest install procedure. No matter how foolproof you make a system, someone will be a bigger fool. You can only look to how many people successfully use the system vs. failures.

And people for whom the system works don’t need to make posts or file bug reports.

If you want maximal adoption, you can adopt the practices that the largest, most popular cross-platform open source projects use.

Which:

1: is no guarantee of “maximal adoption”.
2: requires more time than I care to invest.
3: requires doing things that are against my personal beliefs.

Thank you for the advice. But I’ll keep going with what I have, if it’s all the same to you.

Of course, there’s nothing stopping you (or anyone else) from using the existing distro to make and distribute binaries if that’s what you really think would help. Many, many projects work this way, where the primary developers make the real code and others create various binary distros and such for those who want simpler installations (though most of the time, it is for much more complicated build systems).

In fact, if you took the time you spent writing messages and spent it on “build engineering” for my current SDK distro, I bet you’d have a couple of binary packages available by now :wink:

I’m not going to do it. The only reason the SDK even exists is because it’s derived from my tutorial framework. I felt that I could wrap it up in a nicer package and let people use it directly. If it helps someone, great. If it doesn’t, that’s fine. But I’ve invested about as much attention on having a reasonable build system as I’m going to.

Alfonse, here is my constructive feedback about your approach to all these things. You are a man of very strong, distinct opinions about how anything “should be done.” I’m pretty sure this blinds you to other people’s modalities of engagement. Whether it’s a newbie in this thread trying to use your stuff that gets angry about how you speak to him, or some other person with an idea about opengl32.dll that you give a harsh critique to, or other such as I’ve seen in these forums while researching your posts and coding efforts. You have a lot of energy and drive, and sometimes you have good engineering taste. Other times you just have “your” engineering taste, and it seems like you haven’t spent much time in other areas of public engineering practice. Maybe you took issue with something at some point and decided your way was the “right” way. It really doesn’t matter, as you’re the only one who’s going to work on your tutorials and SDK, so long as you insist on your idiosyncracies. I’m just trying to tell you how other people see things; I can’t make you see or agree.

We have different needs. That’s fine. What makes your needs so much better than mine?

I’ve been trying to figure out if you have any popularity goals typical of SDKs. I conclude that you don’t. There’s a certain way that people bob and weave when they’re trying to get everyone to adopt their stuff.

And that’s the whole point. You believe that VC6 users are not “an important case use”.

I don’t agree. The thing I hate the absolute most when working with Open Source projects is being told what build system to use.

That’s a rather emotional, theoretical, ideological objection. How many VC6 users are actually out there now? It’s open source, they can code it up themselves if they want something particularly weird. Open source is supposed to be a profitable activity. It’s not profitable if you’re doing lots of extra work for weird corner cases that very few people actually need. By “profitable” I mean that anyone’s effort should be weighed against the $X/hour they could be making doing something else.

One of them could not be helped because he refused to actually say what the problem was in a reasonable way.

Actually he could be. You just didn’t want to do it on his terms. “I wrote TFM; you must RTFM.” Well, maybe TFM isn’t as good for a newbie as you believe it to be. Sure you asked him what he thought was wrong with TFM, but you were testy and standoffish about it. As though you really didn’t want to hear that there was something inadequate about it, and just wanted him to get with the program and do his homework.

In fact, if you took the time you spent writing messages and spent it on “build engineering” for my current SDK distro, I bet you’d have a couple of binary packages available by now :wink:

You’re not the kind of project leader I’d hitch my wagon to, frankly. More like a code fork if I cared enough to solve OpenGL’s problems. I don’t know that I want that job. Thanks at least for licensing your code sanely; none of the other extension wrapper projects do.

The only reason the SDK even exists is because it’s derived from my tutorial framework.

Well that explains a lot, if the tutorials came first. You’re into writing tutorials, not SDKs.