Understanding of the build process
closed account (S6k9GNh0)
I've continuously found people saying that some libraries are easier to install than others. I am at a loss as to how this is... most are already completely automated and do everything for you. Even if they aren't, it's generally pretty basic as to what goes where. But I see people who have programmed in C for years without a damn clue as to what is actually going on inside of their build tools or the project they're working on.
But even further, I find it stranger that Java programmers tend not to be this ignorant of their build tools. I know the process is much less complicated but when you ask a C programmer if he's trying to build a static or shared library, and then he asks, "What's the difference" or says, "I don't know", the palm of my hand slowly finds its way onto my face.
Now I'm no expert on ld or any specific toolkit. I know enough to mix builds together, to do some cool stuff with makefiles, and to never, ever have issues with linking or headers. I believe this is enough to quicken my pace as a programmer. But I find people stuck on these things for hours, days, sometimes weeks, basically playing "trial and error" at trying to get things to work.
I'm not really sure how to fix the issue. It's not as complicated as some people make it out to be. Rather an hour or so of reading would set you up for life as to how linking interacts with the compiler and your code.
I'm starting to want to redirect people to the clang or ld manual pages everytime I see someone say Code::Blocks is a compiler. Any feedback on my observations?
But even further, I find it stranger that Java programmers tend not to be this ignorant of their build tools. I know the process is much less complicated but when you ask a C programmer if he's trying to build a static or shared library, and then he asks, "What's the difference" or says, "I don't know", the palm of my hand slowly finds its way onto my face.
Now I'm no expert on ld or any specific toolkit. I know enough to mix builds together, to do some cool stuff with makefiles, and to never, ever have issues with linking or headers. I believe this is enough to quicken my pace as a programmer. But I find people stuck on these things for hours, days, sometimes weeks, basically playing "trial and error" at trying to get things to work.
I'm not really sure how to fix the issue. It's not as complicated as some people make it out to be. Rather an hour or so of reading would set you up for life as to how linking interacts with the compiler and your code.
I'm starting to want to redirect people to the clang or ld manual pages everytime I see someone say Code::Blocks is a compiler. Any feedback on my observations?
closed account (3qX21hU5)
I was actually thinking something along the same lines today. I keep seeing people judge libraries on how easy they are to install and I had the same exact reaction.
I think actually learning how the build process works is one of them things people generally just skip over when they are self taught (I know I did). Why this is I couldn't tell ya (Maybe something to do with IDE's now days and just pressing a button and your good to go who knows).
If someone asked me what I think two things are that most beginners need to know about but don't it would be how the build process works and how to effectively use a debugger.
I think actually learning how the build process works is one of them things people generally just skip over when they are self taught (I know I did). Why this is I couldn't tell ya (Maybe something to do with IDE's now days and just pressing a button and your good to go who knows).
If someone asked me what I think two things are that most beginners need to know about but don't it would be how the build process works and how to effectively use a debugger.
Last edited on
closed account (Dy7SLyTq)
for my two cents... i dont judge a library by how easy it is to install... rather its usefullness. i found sdl very simple to install yet couldnt do as much as sfml, which i had difficulty installing because it requires a lot of dependencies. as too static and shared libraries... isnt static one that is compiled directly into the code and shared is dynamically loaded? just out of curiousity, why would ld man pages tell you the differences between a compiler and ide? isnt ld the linker?
Some libraries really are very difficult to install. For example, Clutter is not easy at all to get installed correctly on Windows. As of now, it's to the point that you should probably not even try, just wait until they fix the broken dependency fetching scripts / provide a reasonable way to get all the dependencies, and fix the rest of their windows build process ( which I am starting to doubt will ever happen ) .
I started using this library a long time ago on a large long term project. At the time it was easy to get working on windows. Then I (maybe foolishly) started adopting new versions of the library as they came out and getting rid of the depreciated stuff. I develop on Linux. Now I want to get it ported to windows again, but the modern versions are not so easy or quick to build for windows. It's too much of a pain for me to even waste any more time on.
I started using this library a long time ago on a large long term project. At the time it was easy to get working on windows. Then I (maybe foolishly) started adopting new versions of the library as they came out and getting rid of the depreciated stuff. I develop on Linux. Now I want to get it ported to windows again, but the modern versions are not so easy or quick to build for windows. It's too much of a pain for me to even waste any more time on.
Last edited on
closed account (S6k9GNh0)
No, see, you're expecting the build scripts to work for you. Windows doesn't use FHS but the method of installation is the exact same. You just figure out what dependencies Clutter-GTK relies on, get the dependencies. Linker errors will tell you what libraries are missing, it even tells you if the library needs to be 32-bit or 64-bit.
Although, I'll admit the GTK implementations for Windows is... lacking to say the least.
Although, I'll admit the GTK implementations for Windows is... lacking to say the least.
closed account (Dy7SLyTq)
i dont expect it to work for me, but if library a requires dependency a, b, and c which are not commonly installed, and library b requires dependcy d which is used by a lot of applications and is probably already installed, then the library will be easier to install
Try building anything on Windows and tell me it's not hard. Try building GCC on Windows and tell me you succeeded.
Building on Linux is a breeze, it's building on Windows that people complain about.
Building on Linux is a breeze, it's building on Windows that people complain about.
closed account (Dy7SLyTq)
well it depends on the project. for example in building sfml i can do that easily on windows. on linux i have to install/update about 20 random dependencies before i even think about building it. clang was really easy to build on linux though
I had a nightmare trying to build SFML on Windows and I just gave up and stopped using clang and moved to nuwen MinGW.
Fun project for this week: build Cairo on Windows. Bonus points if you generate a statically linking library.
Actually, most things I've come across are straightforward to build on VS even if no project is provided, by simply dragging all the sources to a new project and tweaking config.h. It only gets nasty with libraries that have a ton of dependencies, like Cairo, so you have to do this for each dependency. It's not exactly difficult, but it's tedious and time-consuming as hell.
Actually, most things I've come across are straightforward to build on VS even if no project is provided, by simply dragging all the sources to a new project and tweaking config.h. It only gets nasty with libraries that have a ton of dependencies, like Cairo, so you have to do this for each dependency. It's not exactly difficult, but it's tedious and time-consuming as hell.
closed account (z05DSL3A)
| helios wrote: |
|---|
| Fun project for this week: build Cairo on Windows. Bonus points if you generate a statically linking library. |
closed account (G30GNwbp)
I have noticed people who seem to have a greater understanding of the language then me be unable to build and use the boost libraries. I cannot reconcile this.
Libraries are generally easy to build when your system is very similar to what the developers use. This basically means a stock, up-to-date installation of a reasonably popular Linux distro.
Once you step outside of this comfort zone at all, everything breaks down. I've had libraries fail to build simply because the code was on a flash drive where the scripts cannot make symbolic links (even though a simple copy would have worked).
Many libraries expect you to enter options on the command line, but they are rarely documented well. This was an issue with SDL 1.2 on Windows, since for some reason the developers decided that the pre-built library file should stop cout from functioning. Newer build systems like cmake try to alleviate this problem, but they actually make it harder (now I have to go get the exact version of Python they want...).
When you try to compile these libraries on Windows, it often gets a whole lot worse. Open source fans like to complain about Windows noncomformity, but open source code is frequently littered with unnecessary references to nonstandard Unix headers. Once I ran into a problem where a piece of code couldn't find a case-insensitive string compare function (why didn't they just write their own?). Just so we're clear, I'm not talking about compiling in Visual Studio; I'm talking about MinGW, which is gcc and other tools for Windows. You simply cannot get many of the utilities that your average build script expects your system to have.
Once you step outside of this comfort zone at all, everything breaks down. I've had libraries fail to build simply because the code was on a flash drive where the scripts cannot make symbolic links (even though a simple copy would have worked).
Many libraries expect you to enter options on the command line, but they are rarely documented well. This was an issue with SDL 1.2 on Windows, since for some reason the developers decided that the pre-built library file should stop cout from functioning. Newer build systems like cmake try to alleviate this problem, but they actually make it harder (now I have to go get the exact version of Python they want...).
When you try to compile these libraries on Windows, it often gets a whole lot worse. Open source fans like to complain about Windows noncomformity, but open source code is frequently littered with unnecessary references to nonstandard Unix headers. Once I ran into a problem where a piece of code couldn't find a case-insensitive string compare function (why didn't they just write their own?). Just so we're clear, I'm not talking about compiling in Visual Studio; I'm talking about MinGW, which is gcc and other tools for Windows. You simply cannot get many of the utilities that your average build script expects your system to have.
Topic archived. No new replies allowed.