This is just WAY beyond my skill set. I am NOT a command line guy. I avoid it at all possible cost, but lately I find that I am needing it for nearly every open source project I find, especially anything GNU related.

I'm trying to build mpfr, a multi-precision floating point library. I'm not sure I'll need it, but I might and it looks useful, so I try and no luck. I can download the source package, but it requires another library, gmp. I download the archive for gmp and nothing recognizes it as an archive. :/ Hmmm. I find this site, https://sourceforge.net/projects/mingw/files/MinGW/Base/mpfr/mpfr-3.1.2-2/ , but the instructions are just horrible!

Build instructions:
cd working-directory <-- Um... What? OK, the next line is to run mingw, so I'm guessing change the directory to mingw?
mingw-get source mingw32-gmp <-- Success! YAY!
cd mpfr-3.1.2-2-mingw32-src <-- Wait. What? There is nothing in the source archive that I downlaoded and I get an error.
make clean package <-- Can't get this far.
---No idea what the following comments are talking about!---
# See the output of make usage for a detailed list of targets
# You can edit package.ini to modify the configuration items or to increment
# the MPKGRLS value (the -2- after the mingw32).

I am finding build issue after build issue with every GNU project I try to use. I had a heck of a time building GTK+ for Visual Studio, gave up and successfully managed it for Code Blocks, something I am totally prepared to live with, but why? Forget building Cairo by itself! If Cairo changes and I'm interested in the new changes, I'm stuck until GTK+ updates itself with the latest Cairo build and someone then creates a Code Blocks build for that version.

Where do I learn to do this? I know these libraries are built for Linux, but there are many Windows apps that use them, so the developers had to know how. Where do I get this knowledge? What Google turns up pretty much assumes that you already know what you're doing. I am absolutely beyond frustrated!

Wow. I need to not type in frustration! The title should have read: "I need help understanding how to build GNU projects in Windows."

cd working-directory <-- Um... What? OK, the next line is to run mingw, so I'm guessing change the directory to mingw?

I would think mingw is in the PATH (directories containing executable programs which are searched when typing a random command, like "ls" or "gcc", etc).

Such commands work everywhere (although you can still specify the full path to the specific binary if you want, which executes that specific file, instead of trying to find something with the right name from a PATH directory).

mingw-get source mingw32-gmp <-- Success! YAY!

So what did it contain?

In general, source archives start with a top-level directory with the same base name as the archive, to avoid spreading files all over the place in where you happen to be. (But not all, I always check before unpacking.)

cd mpfr-3.1.2-2-mingw32-src <-- Wait. What? There is nothing in the source archive that I downlaoded and I get an error.

Lirterally nothing? Maybe the download failed, and "mingw-get" created an empty file? (I use a Linux system rather than MingW, so I don't have detailed knowledge of all the MingW weirdnesses.)

You just want to go to a directory with the build system files. Typically there are CMake* files (for CMake builds), configure.sh (autotools, pretty much defacto-standard Unix), or a plain Makefile (projects that never bothered to add a proper build system, you typically hack the Makefile to set your preferences, although you seem to be downloading MingW specific stuff, which may have been already fixed for you).

I would think mingw is in the PATH (directories containing executable programs which are searched when typing a random command, like "ls" or "gcc", etc).

Such commands work everywhere (although you can still specify the full path to the specific binary if you want, which executes that specific file, instead of trying to find something with the right name from a PATH directory).

MinGW IS in the PATH. That's one of the things that's confusing me. I messed with this for about two hours last night and got to the point where I was getting an error saying no suitable compiler could be found. I only got that far after switching over to MSYS2 as per the instructions. I'm not entirely sure WHAT MSYS2 is, other than a Linux command line, so I'm not entirely sure why it is needed over Window's command line.

So what did it contain?

In general, source archives start with a top-level directory with the same base name as the archive, to avoid spreading files all over the place in where you happen to be. (But not all, I always check before unpacking.)

By "success", I meant the command completed without giving me an error. The command downloads the GMP library source code, but hides it ever so well. I had to use the Windows search feature to find it after fruitlessly searching for half an hour.

Lirterally nothing? Maybe the download failed, and "mingw-get" created an empty file? (I use a Linux system rather than MingW, so I don't have detailed knowledge of all the MingW weirdnesses.)

The "mpfr-3.1.2-2-mingw32-src.tar.lzma" archive didn't contain any source code, at least not at first glance. For some odd reason, that archive includes another archive with the actual source and a "package.ini" file that unpacks it. This isn't mentioned in the instructions, nor why such a thing would be needed.

You just want to go to a directory with the build system files. Typically there are CMake* files (for CMake builds), configure.sh (autotools, pretty much defacto-standard Unix), or a plain Makefile (projects that never bothered to add a proper build system, you typically hack the Makefile to set your preferences, although you seem to be downloading MingW specific stuff, which may have been already fixed for you).

There are THREE makefiles, MakeFile (no extension), MakeFile.am and MakeFile.in, all of which look to be, for lack of a better description, machine made. I would love to parse the MakeFile and manually create a Visual Studio project, if I could only make sense out of what I'm given.

Understand that this library is the easiest of the ones I've tried. GTK+ and Cairo are lost causes. I don't have the slightest clue where to go with those libraries and they are the two that I actually need for the project I'm working on. What I really need is a tutorial that will teach me how to port over Linux projects to Windows, with details on the structure of MakeFiles, command line everything, what to include in the projects, how to determine, etc. Whatever I would need to do this for any project I find. I cannot find such information. It would seems that the assumption is that anyone wanting to use these libraries or any GNU library already knows how and they make NO allowance for Windows developers.

I only got that far after switching over to MSYS2 as per the instructions. I'm not entirely sure WHAT MSYS2 is, other than a Linux command line, so I'm not entirely sure why it is needed over Window's command line.

Ah, so it's a shell. The last time I used a windows command-line was in the age of Win95 or so, but that commandline is not even comparable with any Unix shell. A shell is a powerful and complete programming language with variables and text substitution. It's not only used for interactive typing commands, but also eg 'make' runs its commands through it, ./configure uses it, etc. It's sort of a scripting layer on top of the plain commands that acts as glue. Many tools willl fail to work without a shell.

The "mpfr-3.1.2-2-mingw32-src.tar.lzma" archive didn't contain any source code, at least not at first glance. For some odd reason, that archive includes another archive with the actual source and a "package.ini" file that unpacks it. This isn't mentioned in the instructions, nor why such a thing would be needed.

The normal procedure is indeed to pull a real source file straight from the Internet, unpack, and build. Apparently the "mingw-get source mingw32-gmp" did some additional stuff (at least now it does). You may want to read what "mingw-get" is doing, under the assumption it's trying to help you. The Internet may be helpful, if you have man-pages installed (and the command has a man-page), "man mingw-get" should give you help too. Note this is generally reference documentation, rather than a tutorial.

There are THREE makefiles, MakeFile (no extension), MakeFile.am and MakeFile.in

Ah, ok, so it's likely an automake project. The Makefile.am files are the real source in that case (unless there is another code generation layer I am not aware of). GNU automake has extensive documentation that you may want to consult.

automake generates an autoconf project, with configure.in (or configure.ac depending on age of the tool) and Makefile.in files. autoconf uses configure.in as input file, and generates the ./configure program. When you run that, it knows what to look for (C compiler, blah library, blup command, etc), and uses the other *.in files (eg Makefile.in) as template for generating the same file but without .in extension, and with the found system information, like GCC=/usr/bin/gcc.

That gives you the Makefile that you can use for "make".

GNU also has documentation for autoconf, libtool (very smart library build program), and conventions in these generated Makefiles with usable targets, and other things for makeing a real GNU program. In case you want to know, look for something like "developing software with GNU" or so.

Understand that this library is the easiest of the ones I've tried. GTK+ and Cairo are lost causes.

That sounds about right, although I have no idea how portable any of these libraries are (or supposed to be).

What I really need is a tutorial that will teach me how to port over Linux projects to Windows, with details on the structure of MakeFiles, command line everything, what to include in the projects, how to determine, etc. Whatever I would need to do this for any project I find. I cannot find such information.

No idea about porting guides, my guess is that very few people actually do this. Makefiles and a lot of other stuff are very well documented by GNU documentation https://www.gnu.org/doc/doc.html is the entry page. Note that "the GNU way" of doing things is just one way. While it likely provides you with a lot of context not all projects are run this way. GNU coding standards https://www.gnu.org/prep/standards/ seems a lot more than just coding standard, maybe useful to browse that too.

Edit: I missed "command line everything". GNU has a Bash manual, I saw, that should help (shell as programming language), otherwise, "unix shell commands" or "unix command line" or so likely give you a zillion Internet pages explaining commonly used commands. O'Reilly used to have a number of books for it too, no idea if you can still obtain them. Further up in complex commands, Linux Powertools comes to mind, not something you'll immediately want, I think.

It would seems that the assumption is that anyone wanting to use these libraries or any GNU library already knows how and they make NO allowance for Windows developers.

I think this is normal, Windows or Apple isn't much better, except it happens to be the system you grew up with, so you had a life-time of studying to learn what you now assume is general knowledge for all :)

Hope this helps.

GNU people are usually Unix people, and they prefer the command line to graphical interfaces. So you're always going to have a hard time there, sadly.

Having said that, getting to understand your command line is important as a programmer. There are various tutorials online but I've never found a good alternative to simply learning as you go. Keep a browser window open ready to search for answers and try not to get daunted every time some Unix guy writes an incomplete instruction that assumes you've been using the CLI for 20 years.

Other assorted comments:

The "mpfr-3.1.2-2-mingw32-src.tar.lzma" archive didn't contain any source code, at least not at first glance. For some odd reason, that archive includes another archive with the actual source and a "package.ini" file that unpacks it.

It's common for Unix archives to contain other archives. In this case LZMA is a compression archive containing a TAR which I'll call a 'concatenation archive'. The TAR joins all the files together into one, then LZMA makes that file smaller. You'll sometimes find .tgz files, which are (if I remember correctly) TAR files that have been GZipped. There are command line tools for all this, and it's useful to have them, but you can usually browse them with 7-Zip too.

What I really need is a tutorial that will teach me how to port over Linux projects to Windows

That won't exist because there is (a) no standard for 'Linux projects' (although makefiles come close) and (b) no standard for Windows projects (although Visual Studio solutions come close). There are lots of makefile tutorials on the web, but they're not always easy to follow, because it's not a simple format. There's a reason that people joke that every makefile is an edited version of a previous makefile, all the way back to the original one. But ultimately you want a simple answer to a difficult problem and that doesn't exist.

But ultimately you want a simple answer to a difficult problem and that doesn't exist.

Ha! :rolleyes: I've given up on "simple"! Right now, I'm willing to dedicate a significant part of my free time to learn this. I'm really just looking for direction and guidance. At the same time, I would be willing to pay someone, if I had the money, to just simply make this work. I'm that frustrated. That wouldn't help me in the long run though.

If you're willing to dedicate a significant part of your free time, I'd suggest the following:

• get access to a Linux box that you can play around in. Sometimes it's easier to follow the (often broken or incomplete) Windows instructions once you've successfully followed the (working, tested) Linux instructions and seen the expected outcomes.
• familiarise yourself with some basic tools, e.g. grep, cat, less, chmod - you don't strictly need them if you're using Windows but being able to do things the Linux way will help when you're already in the MSYS shell, and that knowledge will hopefully transfer to when you need to edit shell scripts or translate Linux instructions into Windows ones.
• grab some simple projects and unpack/build/install them. GTK and Cairo are big, complex projects. Find something trivial, run through the configure / make / make install dance a few times. Get used to the process and possible errors on simple projects and that'll help you on the bigger ones.

If it helps, know that being frustrated at this is completely normal. The people who work on open source and Linux are happy with the command line and can usually avoid using Windows entirely, so they do. It's lucky any of this stuff is ever ported to Windows.

Thanks for the advice. I figure that if I'm going to learn Linux build systems, I might as well learn Linux. I'll be installing Ubuntu shortly.