I've introduced configure a long time ago, but I've forgotten how to do it. I will add it to the github code, so let's try to configure it!
Every time I write a Makefile by myself, I change the library path and link according to the environment and search for the header path, ... And ** Maintenance is difficult for each environment. ** ** ** → configure ** solves this
If you set configure correctly, all of this will be solved without permission.
That's a common explanation.
The features and impressions I think are summarized in 3 lines below.
--The standard library link is very easy --You can check your own build option with ./configure -help. ――It may be difficult to investigate if there is any problem because it solves it without permission.
I wrote various things at the end.
Then, when the error disappears and ./configure → make can be done, it is completed.
The procedure is fixed, but I wonder if it is difficult to get to configure.ac and Makefile.am. Makefile.am and configure.ac should be based on existing code and OSS.
I will describe what I did after the next.
The basics are like this
--Place Makefile.am with SUBDIRS in the folder without src --Specify the target name for the src folder → Target name _XXXX becomes the flag definition of the common Makefile.
Example
SUBDIRS = lib include
# if you don't need install
noinst_LTLIBRARIES = libtimelog.la
# When installing
lib_LTLIBRARIES = libtimelog.la
# Code specification
libtimelog_la_SOURCES = timetestlog.c
You can choose whether to install headers and binaries as well. If you do not install it, it is common to noinst.
# When installing
include_HEADERS= libtimelog.la
# When installing
bin_PROGRAMS = test
It seems that there are various quirks in the description method around here, so it is necessary to investigate if necessary.
Also, it seems that it is possible to put together a common definition like this
common header deifinition
# Put this file on top
AM_CPPFLAGS=-I$(top_srcdir)/include
INCLUDES_PATH=$(top_srcdir)/include
Makefile.am side
# Load that setting with include
include $(top_srcdir)/am.conf
I remember making both dynamic and static, but that's another opportunity.
2018/05/15
How to make both dynamic and static: It looks good just to add LDFLAGS. For example, it is OK if you pass only rpath as follows. If either ** -shared or -static is attached, one will be given priority, so it seems that the point is to not attach either **. Confirmed operation on Ubuntu 18.04
libtimelog_la_SOURCES = timetestlog.c
libtimelog_la_LDFLAGS=-rpath $(libdir)
As for what to do -Add the description of XXX / Makefile to AC_CONFIG_FILES for all the folders to be compiled. -Add necessary options that did not appear in autoscan.
In the latter case, an error will occur during automake and autoreconf, so you can crush them one by one, but it seems to be difficult if you are not used to this.
I came across the following
・ The following error occurs during salty automake
error: no proper invocation of AM_INIT_AUTOMAKE was found.
→ Add the following to configure.ac to deal with
AM_INIT_AUTOMAKE([foreign -Wall -Werror])
AM_PROG_AR
-The following error for the lib folder in autoreconf
libtoolize: Consider adding
AC_CONFIG_MACRO_DIR([m4])' to configure.ac and libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree. libtoolize: Consider adding-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
→ Add the following to configure.ac to deal with
LT_INIT
Now I'm working fine.
For example, a library such as pthread will detect it during autoscan and add and link it to configure.ac without permission. So it's easy to be aware of only the library you created.
You can make your own ./configure options. (And you can also check it properly with ./configure --help. Personally, I was impressed)
For example, if you want to enable / disable debugging with --enable-debug, use ʻAC_ARG_ENABLE`` and ʻAC_DEFINE``.
AC_ARG_ENABLE recognizes enable-option. AC_ARG_ENABLE (option, help message, execution shell when option is specified, default value)
AC_DEFINE will pass a define like -DXXX AC_DEFINE (define name, define value, [description])
It feels like.
I added the treadsafe option like this.
#AC_ARG_ENABLE( option, help message, script code for this option, default value)
AC_ARG_ENABLE(threadsafe,
[ --enable-threadsafe enable to share handle between threads [[default=no]]],
[\
#
case "${enableval}" in
yes) enable_threadsafe=yes ;;
*) AC_MSG_ERROR(bad value for --enable-) ;;
esac],
enable_threadsahe=no)
#check flag and set defile
if test x"${enable_threadsafe}" = x"yes"; then
AC_DEFINE(THREAD_SAFE, 1, [Define to 1 if you want to ensure thread safe])
else
echo "libnotify is disabled"
fi
The help looks like this.
./configure --help
...
--enable-threadsafe enable to share handle between threads [default=no]
It becomes like that at once! It's also convenient because it's easy to manage debug options.
I made a summary about the options. This is here.
――It's really easy to link the standard library without permission (I forget to add rt or something with high probability) ――I'm glad that you can make it with a few descriptions -** Make compile options configure options. Moreover, you can check with help **
It's a personal hobby, but I think it's worth introducing even at the end. The compile option is convenient, but it's difficult to share because it gives the creator a hobby. I forget even if I make it myself. This can be confirmed with ./configure --help without ** documentation maintenance. ** ** People who like implementation do not write documentation, but when it comes to writing help or usage, they write it properly.
――It is difficult to follow the error in the part left to you at the time of introduction
As with all entrusted tools, it is difficult to investigate the cause when something that does not understand the operation inside does not work well. In the old days, when I tried to introduce various things in earnest, I debugged the inside of the configure script steadily and I remember having a lot of trouble finding the cause.
There is a log in config.log, so if you have a proper OSS, this alone will be a stepping stone to track down the cause. If you make it yourself, you will doubt many things.
--I don't understand the behavior when there is a version difference in libtool.
I'm not really sure about libtool.
Cases I met Part 1. It was recognized that it would work if the entity of libtool and ltmain.sh was placed, but when it was used in a high version libtool environment, make failed. (Created on Ubuntu 14.04 → Failed to build on Ubuntu 18.04) → In this case, delete libtool and ltmain.sh and execute autoreconf to solve the problem.
Part 2. On the contrary, when I brought the code to the old libtool environment, ./configure-> make was done, but After editing configure.ac → executing autoreconf, neither build nor autoreconf can be done. (I tried Ubuntu 18.04 → Cent OS 5.1)
If you don't do anything, ./configure and make can be done, but hmm, I'm not sure about this.
It's easy to follow the problem because it is made properly with a proper OSS around here, I think that it is one of the points that the threshold is a little high because I doubt various things if I make it myself.
It's convenient to install and function, but it's hard to get hooked on it, so it seems that your tastes will be different. How is OSS in the world? I saw you checking the version
If you have any problems, I will list them here. TIPS using configure (Although it is a trash can)
https://github.com/developer-kikikaikai/speedtest
The library introduced below has been configured. https://qiita.com/developer-kikikaikai/items/d8839eae7f4491e01671
http://nopipi.hatenablog.com/entry/2013/01/14/025509 https://qiita.com/impepc/items/1bfdfe8ad741def10948 http://capm-network.com/?tag=autotools%E3%83%A9%E3%82%A4%E3%83%96%E3%83%A9%E3%83%AA%E6%A7%8B%E6%88%90%E3%82%B5%E3%83%B3%E3%83%97%E3%83%AB https://stackoverflow.com/questions/28972112/autotools-setup-for-static-and-shared-libraries?utm_medium=organic&utm_source=google_rich_qa&utm_campaign=google_rich_qa http://d.hatena.ne.jp/kakurasan/20090512/p1