C/C++ what is "imake" ???

senenmut

Active Member

Reaction score: 18
Messages: 140

hi there ,

i have seen a book about "imake" with a SNAKE on the cover.
seems better than python.
what is that about ?

Regards
SM
 

SirDice

Administrator
Staff member
Administrator
Moderator

Reaction score: 12,325
Messages: 38,841

Just another way to build source code automatically. Many of these types of tools try to make it easier to build your code on different systems. A lot of the time different systems use different compilers, linkers, etc. Prime example is Linux and FreeBSD for example. On Linux GCC is quite common, on FreeBSD it's LLVM. Both are C/C++ compilers but are different implementations. They have a lot in common but there are also some subtle differences. Project build tools like Meson or Ninja try to make it easier to compile large projects on different systems.
 
OP
senenmut

senenmut

Active Member

Reaction score: 18
Messages: 140

thanks.
yeah , i just want to make "small" tool really good working.
It's heavy enough.
CLANG
 

SirDice

Administrator
Staff member
Administrator
Moderator

Reaction score: 12,325
Messages: 38,841

LLVM/Clang is included with the base OS. So you don't need to install anything for it. Which version of LLVM is going to depend on the version of FreeBSD. FreeBSD 11.4 has 10.0.0, 12.2 has 10.0.1 and 13.0 has 11.0.1.
 
OP
senenmut

senenmut

Active Member

Reaction score: 18
Messages: 140

yeah,
i don't use IDE. And not Building environment (meson etc).
never GNU.
just bare metal UNIX tools.
 

ralphbsz

Son of Beastie

Reaction score: 2,352
Messages: 3,241

OK, if you think you want to learn how to do C / C++ programming, you will have to learn build systems. Build systems have little to do with GUIs. While some IDEs have their own build system, not all do.

What problem do build systems solve? At first, when you write code, everything is in a single source file. You compile it with a single line statement, for example "cc -Wall myprog.c -o myprog", which takes the source in myprog.c, turns it into the executable myprog, and checks for many errors. This works for a little while. Once your program is over ~100 lines long, editing it in a single source file becomes unwieldy. Once you start object-oriented programming, you will want separate header and implementation files for classes or modules. Soon you will have a dozen source files. Compiling a dozen files with a single line statement is insanely complicated, that command line will be hellish. Also, you don't want to compile and link everything, just because you changed one little thing in one file, So you break up the compile into many steps: For each .c or .C file, you create a .o file, which only need to change if that file itself or one of the things it includes changes. After creating all the object files, you quickly link them together.

All a build system is: A prescription that says: when this file changes, it will affect the following object or executable files. It then does the minimum number of steps required to update everything that is affected. Typically, you have different ways to run the build system, one for just compiling for syntax checking, one for creating an executable, one for installing, one for testing, and so on.

So what build systems exist? The oldest one I know of is actually traditional make, written at Bell Labs, early in the development of Unix. Make has been pretty much synonymous with early Unix. The problem with make is that the syntax of its configuration file (a.k.a. makefile) is really awful. The worst feature is that lines are marked by leading whitespace (so it matters how they are indented), and the difference between spaces and tabs is sigfificant! So you can't even see in an editor what you are doing wrong.

Also: To write a makefile, you have to write down exactly what things are affected by each change, that's called the dependencies. Figuring the dependencies by hand is so hard, there is a lot of automation tools for it. But even with auto-generated dependencies, writing makefiles is still no fun at all.

So, if you want to learn traditional Unix style C/C++ programming, learn make and learn makefiles. Even if it is painful.

There have been many attempts to improve on that. Imake was mostly a system in which you wrote more abstract Imakefile, then run a program (I think it was called xmkmf, perhaps because of the silly Unix tradition of never having vowels), which generated a makefile, which you then execute. Most of the time, Imake is even more painful. While many other build systems have been proposed, I haven't seen any take over. Recently, I've started using Bazel, which seems a bit less painful to configure after you have learned the basic, but these are very personal choices.
 

debguy

Well-Known Member

Reaction score: 24
Messages: 275

Imake was made to build Xerox Windows (X Windows, now Xorg).

Imake uses a series of ".tmpl" files to "make Makefile"s. They are macros (via cpp macro). All compiling is a macro somehow we say.

Whenever you build an app based on X, and X changes, all apps in the X "build tree" get rebuilt. These templates provide build variables so every app in the tree rebulds when X does.

Now X org no longer does that: they are PC. In UBUNTU, the .pc are referenced not the Imake.tmpl And it's assumed that apps aren't in the build tree. (they assume Xorg is installed and not building). For Imake they used "import directories" to do the same.

NOTE: this new port (not yet in freeBSD) has imake (for Motif) working on freeBSD (for out-of-X-build-tree build of motif). It requires the xc/config/cf (here, motif/config/cf) and Imake to be fixed for CLANG CPP BUG. (cpp robs spaces and tabs which damage Makefiles and prevents compiling. the project below solves that. you can't use old imake on freeBSD without a fix. they had used @@\ to get around cpp variances but that too failed in time)

 
Top