Nu på tisdag så kommer vi att tillverka kretskort. För att det inte ska bli trångt med utrymme och för att alla som vill ska kunna delta så kommer vi dela på oss. Vi kommer tillverka korten enligt metoden i filmen nedan, så kolla gärna på den.
Såhär ser ritningen på kretskortet ut.
När vi är klara så kommer det förhoppningsvis se ut såhär.
Här är en zip fil med allt projekt material som vi har just nu. Om du vill öppna filerna så rekommenderar vi Eagle.
Hi, in this programming related article I’m going to show you how to use automake, autoconf, libtool and other configuration and build environment tools to automate compilation of your un-organized .c files. To be able to share your C source code with others in a way they can compile and make modifications to it you need these files properly set up.
Part 1 Motivation
Have you ever found yourself listing files in a old hack directory and got a list like this:
closeout.h pathmax.h sys2.h system.h true.c version-etc.h
And no matter how hard you try you cant seem to get it compiling. Or, you have a list like this:
closeout.h pathmax.h sys2.h system.h true.c version-etc.h Makefile
But it still won’t build using “make” because your set of available libraries is not compatible with what’s needed to build this package. Unfortunately the errors you get from trying are way too obscure to figure out what the hell went wrong.
If you do recognize this as a problem then please feel welcome to part two where we will discuss how to start making the foundation for a more general build environment.
Part 2 Start digging
So the directory listing above is parts of the GNU coreutils package from http://ftp.gnu.org/pub/gnu/coreutils/coreutils-5.0.tar.bz2. Which package I used is irrelevant, but what it does is when you run the command ./true it prints the word “true” on the terminal screen.
Before starting install the tools needed: apt-get install build-essential autoconf automake libtool
So with a bunch of source files and nothing else we shall start by using the tool called autoscan from the autoconf package.
From the description of autoscan manual we get this:
NAME autoscan - Generate a preliminary configure.in SYNOPSIS autoscan [OPTION] ... [SRCDIR] DESCRIPTION Examine source files in the directory tree rooted at SRCDIR, or the current directory if none is given. Search the source files for common portability problems, check for incompleteness of 'configure.ac', and create a file 'configure.scan' which is a preliminary 'configure.ac' for that package.
OK, so what this one does is it reads “.c” and “.h” files and looks for “#include” statements and it lists them in a file called configure.scan.
The content of configure.scan file after running autoscan was:
# -*- Autoconf -*- # Process this file with autoconf to produce a configure script. AC_PREREQ(2.60) AC_INIT(FULL-PACKAGE-NAME, VERSION, BUG-REPORT-ADDRESS) AC_CONFIG_SRCDIR([true.c]) AC_CONFIG_HEADER([config.h]) # Checks for programs. AC_PROG_CC # Checks for libraries. # Checks for header files. AC_HEADER_DIRENT AC_HEADER_STDC AC_HEADER_MAJOR AC_CHECK_HEADERS([fcntl.h inttypes.h limits.h locale.h malloc.h memory.h stdint.h stdlib.h string.h strings.h sys/file.h sys/param.h sys/time.h unistd.h utime.h]) # Checks for typedefs, structures, and compiler characteristics. AC_HEADER_STDBOOL AC_C_CONST AC_TYPE_SIZE_T AC_CHECK_MEMBERS([struct stat.st_blksize]) AC_STRUCT_ST_BLOCKS # Checks for library functions. AC_CHECK_FUNCS([atexit setlocale]) AC_OUTPUT
This file is the fundamental description of what source files we depend on in this “package”.
What we want to do now is to rename it, from configure.scan to configure.ac. There is one thing missing in “configure.ac“, it’s a line telling automake (comming to that later) to make its checks.
Edit the file configure.ac and add these two lines:
The file extension “.ac” means it’s a autoconf file, so let’s try autoconf, shall we?
The tool autoconf will in turn read the configure.ac in order to generate a configure script, ready to be used for Makefile generation later.
The configure script is a “/bin/sh script” that will check to see that all libraries needed for compiling are available and it will try to generate a “Makefile” specific to your Machine and OS type.
If you at some point make a change to the configure.ac you should run autoreconf instead of autoconf.
Now this was the configuration part, now let’s take a look at the “make part”.
Now we are going to do something which requires a little bit of manual work. We are going to create an automake file; they have the file extension “.am”
Create a file called “Makefile.am” in this file we are going to describe what we actually want to get as output from compiling this package. In this example I want to be able to run “./true” so I’m going to try to write a Makefile.am which will make true.c the real “true” executable.
Here is what I wrote in my Makefile.am to make true.c the source of “true” the running binary.
AUTOMAKE_OPTIONS= std-options bin_PROGRAMS=true true_SOURCES= true.c LIBS=
The AUTOMAKE_OPTIONS is determining if the program has the standard set of arguments available, like –version or –help so that it can try them to verify that everything was successful after compiling is done.
If you would have some kind of dependency to some external library say for instance “curses“, then it should be LIBS= -lcurses
One really sweet thing coming up with automake is the fact that it knows what you have forgotten to do. If you have forgotten to add a “copying” license file or some other package-related file missing for the build scripts to work, it will add them for you.
Then run automake again to convert the Makefile.am to a Makefile.in which is used to define “make targets”.
A “make target“ is a goal of running make, such as installing a program globally or cleaning or just test compiling in a local folder.
So after running the previous steps “autoscan”,”rename configure.scan to configure.ac”, “edit configure.ac”,”autoconf”,”Create Makefile.am”, “automake –fix-missing”,”automake” we have a environment for building true.c, my file listing now looks like this:
aclocal.m4 closeout.h config.h.in~ configure* depcomp@ Makefile missing@ sys2.h version-etc.h autom4te.cache/ config.h config.log configure.ac INSTALL@ Makefile.am pathmax.h system.h autoscan.log config.h.in config.status* COPYING@ install-sh@ Makefile.in stamp-h1 true.c
Now this is what the package should look like after downloading a tar.gz file from the web and extracting it.
Part 3 Trying, Failing, Trying, Building!
It looks good, so let’s see if it fits!
Let’s assume this fails, for any reason. Then you can go back to the “autoscan“/ “.ac“/”.am” stage and make your changes and try to re-generate.
Using these tools and methods can help you to port and repackage all kinds of projects in the GNU world.
That’s all for now, I hope you can learn to master the wonderful autotools! Kisses and hugs // Kugg
Hi, in this programming related article I’m going to show you how to use automake, autoconf, libtool and other configuration and build environment tools to automate compilation of your un-organized...
- Achtung Telia (pki debacle)
- Mail-liste-issues och Föredragsvisningar 3/3 @ Glassen
- Tre år efter razzian..
- Hacknight 4our, 19-21 October
- Hackitat – A film about political hacking, world wide
- Thursday May 31 soldering/electronics event: instead of regular open lab night
- RåFILM pres: PIXELARIUM – WORKSHOP: 8-BIT POLITICAL TEXT-MODE GRAPHICS
- Hackathon 2012!
- Lördagsforsk aka Saturday Forsk on February 25
- Science Report: Hexayurt model, osmocom cable, remote control tricks