hpr-knowledge-base/hpr_transcripts/hpr1169.txt

Episode: 1169
Title: HPR1169: Autotools
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr1169/hpr1169.mp3
Transcribed: 2025-10-17 20:55:40

---

Just a short note for as a correction for this episode, can you please note that the time
for the HPR Saturday session has changed to 12 midday Eastern Standard Time or 6 in the
evening Central European Time.
Also the recording will pick up again on the 12th of January, so the next session will be
on the 12th of January as 12 midday Eastern Standard Time or 1800 Central European Time.
That's 1700 UTC, thank you.
Hello and welcome to Hacker Public Radio, what you're going to hear is a recording from
the Hacker Public Radio Sunday sessions, Saturday sessions, my bad, let's keep that in.
And the per-b sessions is in order to record content for HPR, so if you want to record
about something or there's something you know a lot about and you won't be at this information,
but you don't really know how to say it or you need somebody to ask questions about it.
Basically, if you can't get your cat or your dog to listen to you and you need a real
human, come along and find some of us here who would prompt you and ask some questions
and what else?
9 a.m. on Mumble on the Linux Basics Mumble Server, 9 a.m. ESD or 3 p.m. or 15 oner
OK, I see we're ready for recording, is everybody familiar with how Configure Scripts work
themselves?
I know you type in Dutch Flash Configure, possibly some options.
Yes, what the Dutch Flash Configure Scripts does is it takes configures the system and
make sure it knows all the variables in order to compile the program for a C-based programs,
for example, it is out where the libraries are, which you are linking and where the header
files are, which you include and it makes sure that it can find those and it can link
correctly and produces an executable instead of an error.
Configure Scripts are also capable of not configurescripts themselves, but what Configure Script
actually does is it creates a make file, it does that in combination with makefile.am,
which is using auto make creates a make file and with that you can run make which does
the actual compilation and make install to install it to the default installation path and
you can also give options to the Configure Script to include support for certain packages
or not include support and change the destination, default destination or where the main pages
are installed.
If we take a look at Configure Dash Dash Help, if you run that, you pretty much
standard list of options, it can help option, version, quiet, all kinds of normal things,
you can specify the bin there, which is where the binary files are installed,
so the executables, well, you can pretty much read what stands there.
Hey, Mito, could I interrupt?
So when you're typing in .slashconfigure, you're obviously following the Configure Script,
which exists in that source code distribution, how does that script there?
Like, how did you as the author of this thing that we're looking at right now?
How did you get Configure into your source code thing?
Like, how do you utilize it as a programmer?
Yes, the Configure Script is actually the output of a program named AutoCon,
and AutoCon or creates the .slashconfigure script out of all kinds of
pre-installed things within the AutoTools suite themselves.
And a script which is also present in pretty much any source download you make,
which has a Configure Scripts, which is either called Configure.ac,
or in older versions is called Configure.in.
If you look at Configure Script included,
you rules which says which it has to do.
And from these macros, these are macros created in M4,
and there's an entire library of M4 macros available on the internet,
and usually downloadable in a package within your distribution.
Macros actually do the configuration.
So, shall we just walk through the script for a moment to the individual opens?
Well, the first one, it says ACBRequest, which is the version of AutoCon,
which is minimally needed in order to configure this script correctly.
There are multiple versions of AutoCon still around some scripts use.
Well, the problem mostly is that you can create a .slash figure which works,
and well, some incompatibilities happen when you create a new version of AutoCon is created.
And you can still hang around on that old version.
I think I just have to cut this out thus that makes no sense.
Anyway, you can configure the minimal version of AutoCon, which is wired.
But for the most, you can ignore that and look at it when problems arise.
The next line is way more interesting, which is the ACA initialization part,
in which it gives the name of the pure program, in this case it's called Derpy.
A 4MACros are constructed in the following sense. As you can see, I'm just realizing this is
actually meant for radio. So for the people who are actually listening, you basically create
you there. You could probably post the link as part of the show notes to Nito,
that way they could literally, if they want to go home and look at it, yeah.
Yes, and then you're just going to have to accept that there's some kind of formatting.
I think that is a better ID.
Yeah, yeah.
Yes, so the AC in it initializes the script. You give the name of the program, the version,
and the address that we can be contacted as the maintainer of the script and nothing special
about that. The next one, AC Config Source there. It tells the AC configuration, the AutoCon,
where it can find the source code or your program. For very small programs, you'll usually just
dump it in the same directory as the AutoConfiguration, but with bigger programs, it can be beneficial
to have a separate source directory in which you only have source files and work from that.
For this example script, we have only one source directory behind, and as you can see,
doesn't really link the directory itself, but it links a file in the directory. That way,
it can also check whether a file is available right now and check if not, because well, if there's
no source compiled, then there's something wrong. Commended outline, the AC config headers,
it creates a configuration or creates a header file, which creates all the definitions of
things which are defined by the script. As you mentioned earlier with the AC in it call,
you define the name of the program, the version, and the email address of the maintainer.
These variables are then defined in a file named config of H, and include in your source,
and then automatically include the correct version number within the source code without
actually hard-toding it somewhere in the source. I don't mean to be funny, but I'm just having
trouble following along. Should I be looking at the config.ac file in the boot directory? It's just
I couldn't find the AC underscore in it, but I couldn't find the separate definition you were
just talking about, where it specifies any paths to files. Am I looking in the wrong place?
The AC in it is on the fifth line. The next one is the ac config as src there. My AC in it
is on the third line, and I'm going to be able to reopen it or something. Are you on the right
or late? Are you looking at W3M or are you looking at DURP at the moment? W3M, so I want to go
into a sub directory too. That's what I thought. Now we switched. I can't tell the moment time.
I'm sorry, I should have. Do you see the link in the channel? Okay, I'm just changing over now.
I'll be with you in a minute. I'll catch up. Okay. This will make a lot more sense to you once
you're on the right config.ac file. I promise. Okay, I'm then carrying on. Yes, already looks better.
I'm starting to think that was crazy. I could understand. For example, if you have
an option in your program, which gives you the version of the program, you can just define
the version of the program here and then command the ac config headers command. Then it creates
a config.h file for you. You can then include and automatically make a habit display the
version of the configure script rate distribution file. Then it already has the right version number
in it and you don't have to configure it anywhere else. Just define it here and use it wherever
you need it. The next line in here is the ac config files, which are configuration files with
reage, which is a make file, which you used to actually make the software. The next file is called
80 local. This one is not used a lot. It's a program or a file used to run a auto test. It's
something I recently included and I'm not perfectly familiar with it yet, but you can also create
them and maybe we'll come and look at that later. Related the 80 local file, the next line is the
ac config test there. That defines a directory in which the test cases are defined and so you can
check whether your install package is actually correct according to include the test cases.
There are macros to do unit testing and you can run separate shell script, which do tests or
you can basically define a whole test. If we move down to the next line and there's any questions
just interrupt me because I'd like to know. If we move down to the next line, there's the ac config
out there. The configure script or auto-conv and auto-make and relate tools, they create a lot of
different files in order to be able to actually configure this software on a lot of different systems,
also missing normal programs like install or LD config and they include all kinds of software
package to actually do the duration. Usually these are dumped in the in the root directory,
but with the ac config out there, you can actually define a separate directory where these
files should be dumped. The next one, AM in its auto-make tells this configure script to also be
prepared for auto-make and in here it also defines the name of the program and the version.
It's in the script above which kind of negates the just define it once and then you're done.
But I'm probably doing something wrong and you should be able to do it in a better way.
I think the commented line which does nothing, then we go to the next line, there's ac config macro
there. As I told you for the macros you see here are all AM4-make macros and these macros are
expanded and expanded and expanded and expanded until eventually you end up with what is the
Dutch fresh config your script and all these macros which are needed in order to expand to this
config your script are included within the district bush, distribution of your software,
so that when somebody else who doesn't happen to have a copy of this,
AM4 macro handy as a copy of the macro used to create this package in the package itself.
Is that a standard convention always include them in case people don't have them themselves?
Yes, that's the main idea of the Dutch fresh scripts. You include everything you need in order
to do the configuration. But they still need to have auto-conf on their system, right?
Or are they getting it when they download your source? They do need, yes and no.
In order to build my software as I distribute it, you don't need to have auto-conv install at all.
You can just do Dutch fresh config your make-make install and you don't need to worry about it at
all. However, if you want to change the software and for example you want to include support
or some other library, then you need to change the configuration, then you do need auto-conf.
I may have a few different macros which do the configuration as you do,
so I include all the macros which I used in order to configure this,
which are in a stand also source code, where exactly as I built it.
And so you don't have to worry too much about differences in versions between
the auto tools macros that you have installed or the auto tool macros which I have installed.
Does that answer your question? Yes, it does perfectly.
Okay, well, if we continue in the script, the next one is there's comments checked for programs.
By the way, if you want to make a configure script yourself or a configure.ac for your own software,
there's another program called Auto Scan which is also part of the auto tool, so you probably
have it installed if your auto-conv installed. It tries to create an auto-conv script
which tries to create an auto-make script with an auto-conv script, which actually works for
your system-fuel libraries, and it gives you the main build-up and it also gives the
comments in this script, like the chat for programs, and the AC Pro CC. The line AC Pro CC basically
tells the auto-conv that there needs to be a C compiler present on the system, and it includes
all the checks whether there's a C compiler, whether it can actually compile usable code.
And most of these things aren't a problem on a standard Linux system, especially if it's a system
for a developer, but it may be more problematic if, for example, you try to run it
on your own home-builder Linux from scratch install or on an exotic hardware with an exotic
operating system which may not have pay. And it's also the thing which makes your
mix scratch without any extra nevermind. The next one is the check for libraries.
You need to see compiler in order to compile C code, but most of the time you're also using
different libraries. For example, you want to include a QT library so you can create nice little
windows, or in this case I'm including a library for SRS, and I'm including a library for
Miltar. SRS stands for sender rewriting scheme, which is a technique in order to rewrite
the destination for an email host, sorry for the email, I'm sorry, SRS, sender rewriting scheme,
it's used in SPF in order to rewrite where the email is sent from. So when a receiving host
does an SPF check and I'm forwarding an email from say google.com, it's not saying that it's sent
from google.com because I'm not allowed to send from there, but it's encoding that comes from
some google.com domain, true scheme, which sends it from my own domain name for the subject right
now. There are multiple ways to look for libraries and from what I have found, the recommended
way is to use AC search lips, which is a macro which looks for function, which is the first argument,
in this case, so SRS new, in a library, which is the second argument, so we're looking for a
library named SRS 2. This actually does is it creates a little program which loads a price to
execute a function named SRS new, so it tries to link that to the SRS library and if that
cleats, well, then the check is completed and it works and can actually use the function SRS
new with that library and everything's happy. The next argument in this command true is what needs
to be done in order when the command succeeds, when the check I just described when it succeeds,
true, well, it's basically nothing, run through, yay, it runs success done. The next argument is
what needs to happen if the check fails. You can do multiple things when a check fails. In this case,
the SRS library is pretty important for my piece of software, so if you don't have an SRS
library installed, I cannot compile my program, so I'm doing a failure. You can with a macro
called AC message, MSG failure, and I give SRS 2.0 library X thing. Here you can define a message,
so when you run Dutchlessconfigure and you don't have that library installed, this is the message
which you're going to get. It's certainly the SRS 2 to find that library to find a function or
something an object called SRS, and that's all new, is that right? If it fails, that is correct.
Okay, great, thank you. If it fails, it gives you the message cannot find SRS 2 library X thing.
The last argument you can give is a particular script, which in this case is empty. Our extra
libraries need to be included in order to compile with this library. For example, if you want to run
a function which does some function in Qt, chances are you're probably going to need the X11 library
as well. So you can define in the final argument of this function to include the library X11,
and you can have done a check for that somewhere here before. The AC search lab, which is for
Milter, it works basically the same, so I guess we'll better spit. So what these checks for these
libraries do is they create some macros which can later be used in the linking step. So when you
link the PC program, it knows, well, we also need the SRS 2 library, and we also need the Milter
library, and they're over here, and everything goes fine. Going down to the next line,
for the check for header files, AC check headers, basically checks whether the
Quilac can find certain header files. There may be a problem one moment. The first check in this line
is for erno.h, signal.h, standard, bull.h, standard.io.h, and all kinds of other standard.
.h files. I've included this in this check to see whether they are present. This should never
fail, and if you don't have one of these files present, then there's a big problem which I
can't help you with. So that's the error that I'm going to give you. Is checking for a header called
SRS 2.h? Well, the first argument to AC check header is what you need to do when it succeeds.
The second argument is, sorry, the first argument is which is the header file which you're
actually looking for. The second is what needs to happen in case this check is correct,
and the third argument is what needs to happen in case this check fails. And here, again, you
can use the AC MSG failure, which gives you an error message. In this case, cannot find the
SRS 2.h header files needed for blah, blah, blah. File, and there's a check for a library file
somewhere earlier. You can actually install the library without installing the header file.
The libraries are usually in the normal packages. So in this case,
the LIP SRS 2 includes enough files in order to satisfy the library check. However,
if you want to compile a program for this, you also need the header files. These are usually
included in the development packages. So the minus dev, or minus dev,
packages in your package manager. I don't know how to do that, but that's why there is a separate
check for the header and for the library itself. Well, there's another check here AC header,
which checks if there's actually, if standard rule, if that is included. I think I also,
I also included sdbool.h in the AC header check. And so that may be superfluous. Am I saying that
correctly? The reason why there is a separate check for sdbool has to do with fact that sdbool
can be only supported within the compiler itself. Again, we're talking all the platforms
and exotic platforms, mostly in this case. But this checks if the compiler actually understands
what to do with the standard rule and if that is correct. AC type sd finds out whether the
variable size t is known by the C compiler. Also, again, not really something to worry about
in standard Linux or any post X compatible system, but it's included. I got it from the AC
send and I didn't think it would be a better good idea to remove it just in case. It also checks
whether the function realloc is available with AC funk realloc. Can I ask you how much of this,
how much of the file here was actually create with the scan that you mentioned. Did you actually have
to make many changes yourself to make it work? How do you do that scan? Well, I had to let's do one now.
Oh, no, let's just finish this up and then we'll answer this, answer your question. The
leftover one's LT in it checks for lip tool, which is used for the linking part. And AC output
tells it to actually produce a dot slash configure script if I'm remembering correctly.
Now regarding your question of how to create a file, it's pretty simple. Just on auto scan,
auto scan, then it's going to give you a few warnings. In this case, because it already finds the
file I had, but then it creates for me a config, a configure that scan file. That easy. Wow, nice.
This is probably going to be a bit of cheating. So I'm going to remove the configure.ac to make
sure it's file for me. It already fills in for anyone who run it. It fills in the pre-request
the version of a autocomph which you need, which it puts on the version which you are running right
now to create the AC in it function. You just need to fill in some information. It won't fix
source there. The config headers. It creates that one, because you usually want to have the conflict
of H, and I didn't want to have it in this time. There's a check for programs, but apparently it
finds that I also need a C++ compiler by including the macro assay pro cx.
Well, this was a mistake. It also says it needs, I need a C pre-processor, which is the AC
underscore pro underscore cpp. It is actually correct in that regard. So I should probably include
that macro in my configure script myself. It says I need an install, which is a program which
pretty much does the same thing as cpp or copy. Lns, you need me able to make symbolic links.
Not particularly sure what makes it does. So I'm sorry. And runlip is again a program needed for
the library checks I had to install myself. AC, the autoscan is not really good at finding
libraries in that regard. Finds some of the header files, which I included. It asks for the standard
pool, the size t. It finds some of the functions you use. The malloc, realloc, standard,
string made. So if you're running, say you're making a hello world program, you can pretty much
auto configure it just by running autoscan and then renaming that and filling in the AC in it
script. The autoscanic creates a file called configure.scanis. Yes, that is correct. And the
configure.scanis is what it exactly as AC script does. So you can just rename it and run
autocomps and have it built a script. It's kind of really interesting because it's
demystifying a lot of this when I've done these builds. I've kind of imagined that it's more
complicated than it is. I'm sure there's some tweak and you have to do. Yeah, you go ahead and
know that it's kind of, we've blown away the magic from the whole thing. I'm sorry to say.
I made it sound simpler. Yeah. But magic is still magic once you understand how it works.
Oh, I meant that in a good way. You know, there's a magic simple file. I really appreciate it.
Indeed. Shall we run through the makefile, the makefile.am and what that actually does?
Yeah, I don't know if I need it line by line, but give me an overview.
Well, what the makefile.am file, that's an input file for auto make. And auto make is the program
which actually creates the makefile. This is the file in which you bind all the extra
flags you want to add to your compiler and where source files are and how the programs
you need to be created and also what has to be included in the distribution packages and
will come to that later. But here who's not really really known with how to compile a source code,
C code. I don't understand the question like familiar with compiling C code. Yes.
Not really. I mean, you mean just gcc in dot c redirect out dot a or something like that?
Is that what you mean? Yes. That's my extent. That's the extent of my knowledge of how to file C code.
Yeah, I'm familiar with the makefiles and yeah, yeah, and you know what I use.
Yes. Well, what what the makefile.am it actually comes down to creating a makefile.
And there's some other tricks, there's some tricks in the makefile which you know, let's just run
through a few of these things and then I'll show you how it actually works.
Okay, can I ask you an overview question at the beginning? I mean, I have experience of writing
just the makefile directly. This is a long time ago, you know, but what's the real advantage
or real reason for making the makefile.am and then automatically making the makefile? What's
the big advantage? Is it cross platform when make environments are different or can you explain that?
That was actually my exact question. There are two reasons. There are two reasons to go with
with the make dot a m file and creating a makefile out of that as opposed to writing the makefile
directly directly. The first one is indeed there are many versions of makearound.
Most of us use a new make, but for example, the open BSD distribution uses the BSD make
which in some regards are different. And Apple, what's its OS name, whatever, they also have a
separate different kind of make program which processes makefiles. Just slightly differently
using makefile.am and having that be a makefile is that you're sure that the makefile work on
anything supported by the makefile.am. Part is that you can define the program which you want to make
and which source files are related to that and the main pages and then have it figure out how to
actually compile it using out on and figuring out where your, for example, your X11 library is
or your Qt library or where the header files are. Whether you need to install into the
lipstick for directory or in the lip directory, it's a flexibility you get from that at the cost
of some complexity in the file. I'm just looking at the file. No, I'm sorry for interrupting you
as well. I'm just looking through it and it doesn't look so confusing. You know, it looks quite
straightforward like a normal makefile to be honest. Yes, the most part is actually a file
or, well, we'll get to that. If we go to the beginning of the file, I define some
AMC flags which are warnings which I like to use when I'm compiled. So when my compiler thinks
I'm not, I'm being not exactly holding myself to the standard and it gives me an error which
I have to fix before it actually allows me to compile. There's the, anybody familiar with the
CFLEX at all? Should I explain what CFLEX are? After them, but I mean, if you could probably shed
some light on the bit. Seconded. Flex are an argument you can give to your make in order to define
which in order to compile or yes, to compile a C program. And for example, if you want to run,
if you want to compile another program which you download on the internet and you want to
download it or you want to compile it, position independent code because you're building a
secure system or whatever. Then you can say dot slash configure, say flags, capital C,
go F capital A, capital G capital G is F minus F pick. And that gives the the argument you give
in this case minus F pick to the, to the second compiler. At the moment, it compiles program which
is in C. Is there a good place to understand all of those options, all of those combinations of
compiler flags to get an idea of what kind of things you can do? Yes, you can do a new project.
So the info file is very valuable in that regard. There's also the new manual which explains
the entire process. There's a lot of things which are actually happening when compiling
C file going down in the details, which usually you don't see because there's some programmer
who has worked on this code and created some file and you just press your and it all works.
There's actually quite a few things happening in there and the manual is really big,
but if you want to know more about how code is compiled and especially how how auto tools work,
the auto make manual is a really good resource on that. Probably say that somewhere in the
beginning of the show or repeated at the end will want to hear it. Before we continue to the file.
That's that's great. Thank you. I'm just looking at the manual now.
Okay. So as I said, the idea is file is used by auto make in order to make a make file and you can
basically bind the programs which it needs to compile. So the executable you want to have in the end,
using a macro or this is not really a macro. How do you call this again?
Bin programs is derpy. Just a program you mean? No, I don't quite follow.
To mean the target variable. I'm the word was variable. Find the variable bin programs,
which tells auto make these other programs which you need to compile. These are the executables you
want to have in the end, which is the name of the program which in this case is derpy.
For each of the programs you list here, so you can have multiple programs all live in the same
source directory. For each of these programs, you can define various factors. For example,
the sources you need to define which are the source files which are needed for which basically
last file. So there's this variable called derpy underscore sources sources in capital letters,
which defines the path to the main and all the other C files which are used in order to create
this program. There's also a list of manuals. You can also create month files and have them included.
Simply include the macro name of the program underscore months, capital letters again.
I really suggest you look to the bird through the file if you want to see it and then you can say
where the manual files are. For as far as I am on the I understand they are usually
hand created. So I used a little heck within this make file within this make file.am in order to
include auto semi-automatically make the manuals program. I happened to have used doxy gen in order
to create the main files. Andri underscore months is a variable which tells these are manuals
which belong in section 3. Section 3 is where the manuals belong for header files and C functions.
And since I only have manuals for the auto generated manuals even for the C functions these
all go into the montrier section. Then there's the variable tradist which is a variable which
say these files are part of the distribution but they're not necessarily used for creating any
source files or at least not in a manner in which auto make is familiar with it in itself.
Test suite variable defines where it can find a program which runs test which you can use
with make check. Auto M4TE must confess I'm not really sure why I included this line.
So yes this is our part of the auto suite and I probably got this from the auto test
auto test program running them. It usually gives you lines you may want to include this line into
your configuration and the lines after this all are lines which are in order to do a few tricks which
are not included in auto make. Do we want to go through that or do we just want to skip that and
keep it within the the auto tools sections. Probably just keep it within our tools.
Yeah then let's just forget all about that and then we're just going to pretend that I
handcrafted the manual files as you probably should. So now we have run through the two files which
created the create the configuration and the make file or the configuration and the configuration
makes the make file. How does it when is this all used? Well how do you actually create the
dot slash your file and I've deleted my album.ac so I can do that. One moment
Qron auto com will automatically create the dot slash conquer file. This includes information
from the make file dot in if you want to make sure you include all the all the different auto tools.
So the auto auto auto make lip tool auto test there is a script which automatically runs all those
programs in the in the appropriate order which is called auto racon frame and you use auto tools
in order to configure them and you alter your make file dot AM you may want to run that in order
to make or all your files are in order again. Well you can run the dot slash configure check whether
well we run through the through the files it will check the the libraries it will check the headers
and I have everything all right so it works right here once you run dot slash configure it will give
you a file which is the make file and you can just run make and then it will compile the program
and create a file named derpy as you find in the make file dot AM can also say for example make
this which creates a distribution file which in this case creates file named derpy dash is dot zero
dot to which version dot dot gz which actually contains everything you need in order to compile.
There's another one you can run which is make this check which creates this file which I explained
earlier and then tries to create program within that file within that directory I'm sorry so you are
sure everything is in order in your distribution file it compiles and it's in everything is included.
If you run it right now you will find it fills in the test suite because I'm not really ready
with creating tests with this program a nice helpful file which a nice helpful message would say
there's some file named test suite dot log and please send to the email address of the maintainer
yeah and it does make install and so about configures. I guess just a sort of overall thing like so
if I was going to try to use this on something first up it sounds like would be auto scan and then
go through and edit your little scripts and figure out what macros you want to use and that's it.
Yes well yes that's the first step and with that you can create a script which does
which does all the checking we discuss. So you can say like yes the the configure.in or
configure.ac they're essentially the same file so people can run dot slash configure and they say
there's problem I don't have this in this library. Yes. I didn't quite follow at what point on
and how do you create the main configure I'm script you know from the the configuring or configure.ac
or what would you run on the mindline to get it to do that. In order to do that you need to configure.ac
or the configure.ain file and you just run out of home. Okay one more question then
is there a point in having a dot slash and figure if you're over I guess I think I'm answering
my own question as I say it but I was going to say is there a chance of having dot is there a
reason for having that dot slash configure if you're going to just write your own make file anyway
is the point of the dot the configure to generate a make file then. No and that's the
point where people where auto make kind of gets its reputation out of tools the configure script
doesn't necessarily make a make file can also make you can also have a configure script and make
your own make file as you said and then you can still take advantage of the fact that the
configure script tells you like hey you don't have a disk in this library installed. Right okay I got
and you can also take advantage of other of the configure script like for example the creation
of a config h file so you can always use the same version number everywhere in your code
or the program name or does the auto conf generate like a template for your make file or have
you got to create that file completely yourself you know. The make file is created essentially
from the make file dot am and the make file dot am well yes you have to create yourself but
for for for an example the like hello world all you need to define is like bin programs underscore
programs is hello world just then is the name of the program and then say hello hello world
underscore sources is and then the name of the source file and then you're done in the file
everything else is just I guess in the documentation the like a simple state like you just said is
described with explanation of all the other things you can add in there yes it has a it has a
configure has some examples and you can also look at where and on the new dot org site the software
there's also the hello world which is the most elaborate hello world file I've ever seen and it also
has a fairly a fairly auto sorry make file dot am that's also a nice one to look at and also when
you download some source and you find the dot slash I'll why not take a look at these two other
files and see what actually makes the program do what it does and that's really interesting it's
really demystified it a little bit for me thank you very much you're welcome I'm here you know
I'm also having a channel from back which is do you only need to run autocom do you need to run
autocomph if dot slash configure doesn't work for you or the provided dot slash configure
the answer to that unfortunately or hopefully is no the the file which is distributed with the
on which is created by running the autocomph should be the same think you mean that's the
configure and it what sorry I'm gonna say I think he means if there isn't a configure like if
there isn't a configure script already generated in the source code like if getting it from SVN
or something like that in that case yes in that case provided then the dot the configure dot
a c file and the make file dot a m file and or are are present can just run autocomph and then
it will create the dot slash configure file indeed does that answer your question yes okay are
there any more questions sounds like I might be a rap yes I think so
you have been listening to Hacker Public Radio or Hacker Public Radio does our we are a community
podcast network the releases shows every weekday Monday through Friday today show like all our
shows was contributed by a HBR listener like yourself if you ever consider recording a podcast
then visit our website to find out how easy it really is Hacker Public Radio was founded by the
digital dot pound and the economical and computer cloud HBR is funded by the binary
revolution at binref.com all binref projects are crowd-responsive by linear pages
from shared hosting to custom private clouds go to lunar pages.com for all your hosting needs
unless otherwise stasis today's show is released under a creative comments
attribution share a like three does our license