奥深さの前に使い方がさっぱり分からん。教えて下さい。
関連サイトは>>2
Autoconf,Automakeについて
1名無しさん@お腹いっぱい。
NGNG2006/12/24(日) 20:13:53
noinst_ だったらコンビニエンスライブラリになるから、実行形式の方には最終的に静的リンクされて .la なんか不要になるはず。
207名無しさん@お腹いっぱい。
2007/06/23(土) 21:05:43 AC_CHECK_HEADERなどで宣言されるHAVE_*の先頭に識別子をつけることはできる?
#define HOGE_HAVE_MEMORY_H
となるような。
hoge_config.hをライブラリのヘッダーから読み込もうと思っているのですが
ライブラリを使う側にHAVE_*が影響してしまうので
ライブラリのコンパイル後に消すか、名前を変えるかしたい。
しかし、ライブラリヘッダーが提供する構造体要素の型をHAVE_*を見て切り替えたいので
単純にconfigヘッダーをインストールしないというわけにもいかず。
#define HOGE_HAVE_MEMORY_H
となるような。
hoge_config.hをライブラリのヘッダーから読み込もうと思っているのですが
ライブラリを使う側にHAVE_*が影響してしまうので
ライブラリのコンパイル後に消すか、名前を変えるかしたい。
しかし、ライブラリヘッダーが提供する構造体要素の型をHAVE_*を見て切り替えたいので
単純にconfigヘッダーをインストールしないというわけにもいかず。
2007/06/24(日) 05:32:53
>207
とりあえず、autoconf-2.61 でだけど。
本論と関係ないけど、AC_CHECK_HEADER は HAVE_* を自動で定義してくれなくて、AC_CHECK_HEADERS が、HAVE_* を自動で定義してくれるような。
で、
AC_CHECK_HEADER(test.h, AC_DEFINE(HOGE_HAVE_TEST_H, [], [Define to 1 if you have the <test.h> header file.]))
みたいな感じで自前で書けばいいと思う。autoheader も拾ってくれてるみたいだし。
デフォルトで定義されてしまう分(configure 自体に使用される)についても名前を差し替えたい場合には、_AC_INCLUDES_DEFAULT_REQUIREMENTS か
AC_INCLUDES_DEFAULT の再定義が必要。
ここまで書いて思ったんだけどさ、ライブラリ作成環境と実行環境で HAVE_* の状態が違っているなら正常動作しなくても当然なんじゃない?
とりあえず、autoconf-2.61 でだけど。
本論と関係ないけど、AC_CHECK_HEADER は HAVE_* を自動で定義してくれなくて、AC_CHECK_HEADERS が、HAVE_* を自動で定義してくれるような。
で、
AC_CHECK_HEADER(test.h, AC_DEFINE(HOGE_HAVE_TEST_H, [], [Define to 1 if you have the <test.h> header file.]))
みたいな感じで自前で書けばいいと思う。autoheader も拾ってくれてるみたいだし。
デフォルトで定義されてしまう分(configure 自体に使用される)についても名前を差し替えたい場合には、_AC_INCLUDES_DEFAULT_REQUIREMENTS か
AC_INCLUDES_DEFAULT の再定義が必要。
ここまで書いて思ったんだけどさ、ライブラリ作成環境と実行環境で HAVE_* の状態が違っているなら正常動作しなくても当然なんじゃない?
2007/06/24(日) 12:30:43
ライブラリのヘッダでconfig.hを読むってのが変だと思うけどなあ。
210名無しさん@お腹いっぱい。
2007/06/24(日) 22:52:30 >>208
どうも。
AC_CHECK_HEADERSで自己定義して、定義しても自動ででてるーと思ってました。
AC_CHECK_HEADERならでないのですか。
>>209
例えば、
#if HAVE_INTTYPES_H
#include <inttypes.h>
#elif HAVE_STDINT_H
#include <stdint.h>
#else
# ..... 自己定義
#endif
#if HAVE_SYS_STYPES_H
#.......略
typedef size_t my_size_t ;
typedef uint32_t my_uint32_t ;
typedef struct libraryargs {
my_size_t length;
my_uint32_t data;
} libraryargs;
DECLARE_EXPORT my_bool_t library_function(libraryargs *args);
というのがあると、size_tやuint32_tが実際なに型なのかconfigureで作ると思っていて
その結果をライブラリコンパイル時に使っているので
ライブラリを使う側も同じ型を使って欲しいと思うんです。
それをまた#ifdef _WIN32でやっているとconfigureの意味が無いというか。
普通どうやるんでしょ?
どうも。
AC_CHECK_HEADERSで自己定義して、定義しても自動ででてるーと思ってました。
AC_CHECK_HEADERならでないのですか。
>>209
例えば、
#if HAVE_INTTYPES_H
#include <inttypes.h>
#elif HAVE_STDINT_H
#include <stdint.h>
#else
# ..... 自己定義
#endif
#if HAVE_SYS_STYPES_H
#.......略
typedef size_t my_size_t ;
typedef uint32_t my_uint32_t ;
typedef struct libraryargs {
my_size_t length;
my_uint32_t data;
} libraryargs;
DECLARE_EXPORT my_bool_t library_function(libraryargs *args);
というのがあると、size_tやuint32_tが実際なに型なのかconfigureで作ると思っていて
その結果をライブラリコンパイル時に使っているので
ライブラリを使う側も同じ型を使って欲しいと思うんです。
それをまた#ifdef _WIN32でやっているとconfigureの意味が無いというか。
普通どうやるんでしょ?
2007/06/24(日) 23:10:23
>>208
>ライブラリ作成環境と実行環境で HAVE_* の状態が違っているなら正常動作しなくても当然なんじゃない?
動作というより、他のプログラムが使う可能性のあるマクロ名を汚染してしまうのが嫌。
Cだから仕方が無いといえばそうだけど、せめてHOGE_*にしてあげたい。
>ライブラリ作成環境と実行環境で HAVE_* の状態が違っているなら正常動作しなくても当然なんじゃない?
動作というより、他のプログラムが使う可能性のあるマクロ名を汚染してしまうのが嫌。
Cだから仕方が無いといえばそうだけど、せめてHOGE_*にしてあげたい。
2007/06/25(月) 00:46:53
不要なものをhoge_config.h.inから削除するとhoge_config.hに反映されないことに気づきました。
2007/06/25(月) 17:54:39
214名無しさん@お腹いっぱい。
2007/06/25(月) 23:28:01 >>213
自分で判断というのはhogeが定義してあるのでOSはhageだとかCPUはfooだとかで
つまり4バイト数値型はhoge_intとかですか。
それがconfigureでやることではないのですか?
自分で判断というのはhogeが定義してあるのでOSはhageだとかCPUはfooだとかで
つまり4バイト数値型はhoge_intとかですか。
それがconfigureでやることではないのですか?
2007/06/26(火) 18:44:44
2007/07/07(土) 22:49:39
>215
ライブラリを使う側でいちいちどのマクロを定義してやる必要があるかを考えるのが面倒くさい…と思ったんだけど、
そのライブラリ用に Autoconf マクロを作ってしまうというのでその点は解決するか。
その上で、ヘッダ側では
#ifdef HAVE_CONFIG_H
#include <config.h>
#endif
しておけば OK かな。
ライブラリを使う側でいちいちどのマクロを定義してやる必要があるかを考えるのが面倒くさい…と思ったんだけど、
そのライブラリ用に Autoconf マクロを作ってしまうというのでその点は解決するか。
その上で、ヘッダ側では
#ifdef HAVE_CONFIG_H
#include <config.h>
#endif
しておけば OK かな。
2007/07/08(日) 20:43:24
>>216
うん。ライブラリ側で、hoge.m4作って、share/aclocal以下にインストールしてあげる。
hoge.m4はAC_DEFINE()とか、一部AH_VERBATIM()とかでconfig.h.inに追加する感じ。
結構面倒な作業になるのかもしれないけど、、、
まあ、hoge_config.h.inから作るってのも解決方法の一つかもしれないけど、
どっちが良いかはよく分からないです。
うん。ライブラリ側で、hoge.m4作って、share/aclocal以下にインストールしてあげる。
hoge.m4はAC_DEFINE()とか、一部AH_VERBATIM()とかでconfig.h.inに追加する感じ。
結構面倒な作業になるのかもしれないけど、、、
まあ、hoge_config.h.inから作るってのも解決方法の一つかもしれないけど、
どっちが良いかはよく分からないです。
2007/07/23(月) 03:24:18
CFLAGSとCPPFLAGSの違いがよくわかりません
Cプリプロセッサフラグってどういうことでしょうか?
-I/fuga/fuge/
をコンパイル時に指定したい場合、
CFLAGS=-I/fuga/fuge/
だと追加されなくて
CPPFLAGSに指定すると追加されてました。
ちなみにC++のファイルです。
Cプリプロセッサフラグってどういうことでしょうか?
-I/fuga/fuge/
をコンパイル時に指定したい場合、
CFLAGS=-I/fuga/fuge/
だと追加されなくて
CPPFLAGSに指定すると追加されてました。
ちなみにC++のファイルです。
2007/07/23(月) 11:01:31
なぜそこで
> Cプリプロセッサフラグ
という自分の推測が間違っているということを疑わないのか。
> Cプリプロセッサフラグ
という自分の推測が間違っているということを疑わないのか。
2007/07/23(月) 19:01:58
いや、推測じゃないです。
http://sources.redhat.com/automake/automake.html
で
CPPFLAGS
C/C++ preprocessor flags
となってます。
http://sources.redhat.com/automake/automake.html
で
CPPFLAGS
C/C++ preprocessor flags
となってます。
2007/07/23(月) 21:04:35
まず問いたい。
おまえはそれを見て、それが正解だと推測したわけだよな?
公式のマニュアルではなく、なぜそんな下らんもので推測したんだ?
おまえはそれを見て、それが正解だと推測したわけだよな?
公式のマニュアルではなく、なぜそんな下らんもので推測したんだ?
2007/07/23(月) 22:30:52
>>221
いや、これ、infoのhtml版だから、ほぼ正式と思っていいと思う。
>>218
http://sources.redhat.com/automake/automake.html#C_002b_002b-Support
CXXFLAGSがC++のときのCFLAGSみたいなもの
プリプロセッサとは、
http://e-words.jp/w/E38397E383AAE38397E383ADE382BBE38383E382B5.html
これでも読んでくれ。#includeを処理するのが何か分かれば
多分理解できると思う。
いや、これ、infoのhtml版だから、ほぼ正式と思っていいと思う。
>>218
http://sources.redhat.com/automake/automake.html#C_002b_002b-Support
CXXFLAGSがC++のときのCFLAGSみたいなもの
プリプロセッサとは、
http://e-words.jp/w/E38397E383AAE38397E383ADE382BBE38383E382B5.html
これでも読んでくれ。#includeを処理するのが何か分かれば
多分理解できると思う。
2007/07/23(月) 23:56:05
ありがとうございます。
プリプロセッサの処理にコマンド指定できるんですね・・・知らんかったです。
C++でのオプションはCXXFLAGSで指定します。
サンクスでした
プリプロセッサの処理にコマンド指定できるんですね・・・知らんかったです。
C++でのオプションはCXXFLAGSで指定します。
サンクスでした
2007/07/24(火) 23:43:52
まず問いたい。
>という自分の推測が間違っているということを疑わないのか。
という発言が出てくるのか。
CPPFLAGSがC++用フラグだとでも自分の推測で発言したのか?w
>という自分の推測が間違っているということを疑わないのか。
という発言が出てくるのか。
CPPFLAGSがC++用フラグだとでも自分の推測で発言したのか?w
2007/11/28(水) 22:49:28
bin_PROGRAMS=/tmp/fuga
とか出来ないんですけど、/tmp/下に生成したい場合とかどうすればいいんですか?
とか出来ないんですけど、/tmp/下に生成したい場合とかどうすればいいんですか?
2007/11/29(木) 08:39:52
できるかどうかわからないけど、なぜそういうことをしたいのか
の目的がわかれば、別の解決法が出てくるかもね。
の目的がわかれば、別の解決法が出てくるかもね。
2007/11/29(木) 11:49:47
自分のホームディレクトリにソースがあったとしても、
/tmp/でmakeしたいんです。
/home/my/src/"ここにソースがある"
けど、makeを叩くことで、
/tmp/でビルドさせたいんです。
/tmp/でmakeしたいんです。
/home/my/src/"ここにソースがある"
けど、makeを叩くことで、
/tmp/でビルドさせたいんです。
2007/11/29(木) 19:43:54
>>227
> 自分のホームディレクトリにソースがあったとしても、
> /tmp/でmakeしたいんです。
/tmp で/home/my/src/configure
すれば、/tmp以下にMakefileができると思うけど。
そういう話ではない?
> 自分のホームディレクトリにソースがあったとしても、
> /tmp/でmakeしたいんです。
/tmp で/home/my/src/configure
すれば、/tmp以下にMakefileができると思うけど。
そういう話ではない?
2007/11/29(木) 23:14:50
Makefileの中身が相対パスで書かれてるみたいなので、
/tmpでmakeをしてもエラーが出るんですよね・・・
やっぱり、ソースツリーを全部/tmpにコピーってconfigure,makeした方が
早いですかね?
/tmpでmakeをしてもエラーが出るんですよね・・・
やっぱり、ソースツリーを全部/tmpにコピーってconfigure,makeした方が
早いですかね?
2007/11/30(金) 09:52:32
それは多分そのプログラムの方が悪い(autotoolsの使い方の問題)。
tmpに全部コピーした方が早そう。
tmpに全部コピーした方が早そう。
2007/12/01(土) 02:00:10
普通、相対パスで書かないものですか?
2007/12/01(土) 09:41:28
2007/12/18(火) 17:33:38
prog_SOURCESにカレントディレクトリ以外のファイルを以下のように指定すると
my_src_dir=/home/xxx/src/
prog_SOURCES=$(my_src_dir)test.c
生成されるMakefileに
include ./$(DEPDIR)/prog-$(my_src_dir)test.Po
という記述がされて、
./deps/prog-/home/xxx/src/test.Po
を見に行ってしまいエラーになってしまいます。
回避する方法ってありますか?
my_src_dir=/home/xxx/src/
prog_SOURCES=$(my_src_dir)test.c
生成されるMakefileに
include ./$(DEPDIR)/prog-$(my_src_dir)test.Po
という記述がされて、
./deps/prog-/home/xxx/src/test.Po
を見に行ってしまいエラーになってしまいます。
回避する方法ってありますか?
2007/12/18(火) 23:29:27
>233
my_src_dir=/home/xxx/src
prog_SOURCES=$(my_src_dir)/test.c
だったら通ったりしない?
って絶対パスじゃないと駄目なの?そーいうのはソースじゃなくてライブラリにしないか?
my_src_dir=/home/xxx/src
prog_SOURCES=$(my_src_dir)/test.c
だったら通ったりしない?
って絶対パスじゃないと駄目なの?そーいうのはソースじゃなくてライブラリにしないか?
2007/12/19(水) 20:40:41
あちこちにあるファイルを集めて一つのディレクトリツリーを作りたいんですが、
なんかうまいやりかたは無いんでしょうか
a/b/c/hoge : d/e/hoge
install ...
a/b/c/huga : f/g/huga
...
とか延々と書くのが面倒臭いんです...
なんかうまいやりかたは無いんでしょうか
a/b/c/hoge : d/e/hoge
install ...
a/b/c/huga : f/g/huga
...
とか延々と書くのが面倒臭いんです...
2007/12/23(日) 11:19:48
237sage
2008/11/15(土) 00:31:39 同じソースファイルを使って、実行ファイルと共有ライブラリを
作りたいのですが、
‘created with both libtool and without’エラーが吐かれて、
うまくいきません。
http://www.gnu.org/software/automake/manual/html_node/Libtool-Issues.html
の8.3.9.2 Objects ‘created with both libtool and without’
に解決らしき記述があるのですが、意味がわからず困っています。
どうしろと書いてあるのでしょうか?
作りたいのですが、
‘created with both libtool and without’エラーが吐かれて、
うまくいきません。
http://www.gnu.org/software/automake/manual/html_node/Libtool-Issues.html
の8.3.9.2 Objects ‘created with both libtool and without’
に解決らしき記述があるのですが、意味がわからず困っています。
どうしろと書いてあるのでしょうか?
2008/11/15(土) 11:13:40
>>237
そこの
> A workaround for this issue is
以下をていねいに読めばだいたいわからんかな?
prog_CFLAGS = $(AM_CFLAGS)
を追加して、副作用として prog.c と foo.c が prog-prog.o と prog-foo.o に
コンパイルされるようにする(そうすることで、ライブラリのほうの
オブジェクトファイルと、名前がぶつからないようにする)、とある。
そこの
> A workaround for this issue is
以下をていねいに読めばだいたいわからんかな?
prog_CFLAGS = $(AM_CFLAGS)
を追加して、副作用として prog.c と foo.c が prog-prog.o と prog-foo.o に
コンパイルされるようにする(そうすることで、ライブラリのほうの
オブジェクトファイルと、名前がぶつからないようにする)、とある。
2009/06/28(日) 12:09:38
linuxなんですがAutoconf,Automakeについて質問してもいいですか?
2009/08/10(月) 13:58:44
どうぞ
2011/04/12(火) 05:29:50.46
hoyu
2012/10/19(金) 00:16:16.94
2014/04/07(月) 01:55:27.82
llvm bitcodeを中間コードとしてビルドするようなmakefileをautotoolsで作れませんかね?
244名無しさん@お腹いっぱい。
2014/09/25(木) 18:45:01.21 Autotools: A Practitioner's Guide to GNU Autoconf, Automake, and Libtool
ttp://books.google.co.jp/books?id=HBbKghM2fGYC&dq=Autotools&hl=ja&source=gbs_navlinks_s
ttp://books.google.co.jp/books?id=HBbKghM2fGYC&dq=Autotools&hl=ja&source=gbs_navlinks_s
2015/01/03(土) 09:15:56.58
--with-* と --enable-* との使い分け方が解らない。
http://www.geocities.co.jp/SiliconValley-Oakland/3432/man/autoconf/autoconf-ja_9.html
を読んでも解らない。
どっちを使っても良いのかな?
http://www.geocities.co.jp/SiliconValley-Oakland/3432/man/autoconf/autoconf-ja_9.html
を読んでも解らない。
どっちを使っても良いのかな?
2015/01/03(土) 21:25:10.13
ぐぐったら入力途中で候補にautoconf with vs enableというのが出てきたので
その結果を見てみたらいろいろと議論はあるようだ。
https://mail.python.org/pipermail/python-dev/2001-January/011991.html
ここの解説だと、機能の有無を決めるのにenable、依存するパッケージとかの
指定にwithを使うという感じみたい。それでも例外もあるようだ。
その結果を見てみたらいろいろと議論はあるようだ。
https://mail.python.org/pipermail/python-dev/2001-January/011991.html
ここの解説だと、機能の有無を決めるのにenable、依存するパッケージとかの
指定にwithを使うという感じみたい。それでも例外もあるようだ。
2015/01/03(土) 23:36:29.26
2015/01/04(日) 00:09:09.26
英語の意味通りですな
2015/01/06(火) 19:37:27.79
キター!
From: Stefano Lattarini <stefano.lattarini@gmail.com>
To: Automake List <automake@gnu.org>
Cc: info-gnu@gnu.org, autotools-announce@gnu.org
日付: 2015年1月6日 19:19
件名: GNU Automake 1.15 released
We are pleased to announce the GNU Automake 1.15 minor release.
(snip)
Download here:
ftp://ftp.gnu.org/gnu/automake/automake-1.15.tar.gz
ftp://ftp.gnu.org/gnu/automake/automake-1.15.tar.xz
From: Stefano Lattarini <stefano.lattarini@gmail.com>
To: Automake List <automake@gnu.org>
Cc: info-gnu@gnu.org, autotools-announce@gnu.org
日付: 2015年1月6日 19:19
件名: GNU Automake 1.15 released
We are pleased to announce the GNU Automake 1.15 minor release.
(snip)
Download here:
ftp://ftp.gnu.org/gnu/automake/automake-1.15.tar.gz
ftp://ftp.gnu.org/gnu/automake/automake-1.15.tar.xz
2017/06/25(日) 07:39:08.66
2年ぶり!
From: Mathieu Lirzin <mthl@gnu.org>
To: <automake@gnu.org>
Subject: GNU Automake 1.15.1 released
Date: Mon, 19 Jun 2017 22:50:34 +0200
Message-ID: <87shivem79.fsf@gnu.org>
We are pleased to announce the GNU Automake 1.15.1 maintenance release.
From: Mathieu Lirzin <mthl@gnu.org>
To: <automake@gnu.org>
Subject: GNU Automake 1.15.1 released
Date: Mon, 19 Jun 2017 22:50:34 +0200
Message-ID: <87shivem79.fsf@gnu.org>
We are pleased to announce the GNU Automake 1.15.1 maintenance release.
251名無しさん@お腹いっぱい。
2017/12/29(金) 07:37:16.28 誰でも簡単にパソコン1台で稼げる方法など
参考までに、
⇒ 『宮本のゴウリエセレレ』 というブログで見ることができるらしいです。
グーグル検索⇒『宮本のゴウリエセレレ』
CAEY39R21B
参考までに、
⇒ 『宮本のゴウリエセレレ』 というブログで見ることができるらしいです。
グーグル検索⇒『宮本のゴウリエセレレ』
CAEY39R21B
252名無しさん@お腹いっぱい。
2018/05/22(火) 06:13:54.01 知り合いから教えてもらったパソコン一台でお金持ちになれるやり方
時間がある方はみてもいいかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
CGFTL
時間がある方はみてもいいかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
CGFTL
2020/03/22(日) 17:23:39.15
過疎化してますね、このスレ.
From: Jim Meyering <jim@meyering.net>
To: info-gnu@gnu.org
Subject: automake-1.16.2 released [stable]
Date: Sat, 21 Mar 2020 17:51:38 -0700
Message-ID: <m2eetlp5yd.fsf@meyering.net>
List-Archive: <https://lists.gnu.org/archive/html/automake>
Cc: automake@gnu.org
This is to announce automake-1.16.2, a stable release.
There have been 38 commits by 12 people in the two years
(almost to the day) since 1.16.1. Special thanks to Karl Berry
for doing a lot of the recent work preparing for this release.
See the NEWS below for a brief summary.
From: Jim Meyering <jim@meyering.net>
To: info-gnu@gnu.org
Subject: automake-1.16.2 released [stable]
Date: Sat, 21 Mar 2020 17:51:38 -0700
Message-ID: <m2eetlp5yd.fsf@meyering.net>
List-Archive: <https://lists.gnu.org/archive/html/automake>
Cc: automake@gnu.org
This is to announce automake-1.16.2, a stable release.
There have been 38 commits by 12 people in the two years
(almost to the day) since 1.16.1. Special thanks to Karl Berry
for doing a lot of the recent work preparing for this release.
See the NEWS below for a brief summary.
2020/11/22(日) 07:21:08.96
このスレ見てる人いるんだろうか?
From: Jim Meyering <jim@meyering.net>
To: autotools-announce@gnu.org, automake@gnu.org, info-gnu@gnu.org
Subject: automake-1.16.3 released [stable]
Date: Wed, 18 Nov 2020 20:51:52 -0800
Message-ID: <m28sayuexj.fsf@meyering.net>
List-Archive: <https://lists.gnu.org/archive/html/autotools-announce>
This is to announce automake-1.16.3, a stable release.
There have been 62 commits by 15 people in the 35 weeks since 1.16.2.
Special thanks to Karl Berry and Zack Weinberg for doing so much of the work.
See the NEWS below for a brief summary.
Thanks to everyone who has contributed!
From: Jim Meyering <jim@meyering.net>
To: autotools-announce@gnu.org, automake@gnu.org, info-gnu@gnu.org
Subject: automake-1.16.3 released [stable]
Date: Wed, 18 Nov 2020 20:51:52 -0800
Message-ID: <m28sayuexj.fsf@meyering.net>
List-Archive: <https://lists.gnu.org/archive/html/autotools-announce>
This is to announce automake-1.16.3, a stable release.
There have been 62 commits by 15 people in the 35 weeks since 1.16.2.
Special thanks to Karl Berry and Zack Weinberg for doing so much of the work.
See the NEWS below for a brief summary.
Thanks to everyone who has contributed!
2020/12/30(水) 10:59:12.06
誰も気にしてないと思うが、今月autoconfが新しくなった。
https://lists.gnu.org/archive/html/autoconf/2020-12/msg00002.html
To: info-gnu@gnu.org, autoconf@gnu.org
Subject: autoconf-2.70 released [stable]
Message-Id: <4Cr8xf5THLzcbc@panix1.panix.com>
Date: Tue, 8 Dec 2020 14:14:30 -0500 (EST)
From: Zack Weinberg <zackw@panix.com>
We are pleased to announce stable release 2.70 of GNU Autoconf.
This release includes eight years of development work since the
previous release, 2.69. Noteworthy changes include support for the
2011 revisions of the C and C++ standards, support for reproducible
builds, improved support for cross-compilation, improved compatibility
with current compilers and shell utilities, more efficient generated
shell code, and many bug fixes. See below for a detailed list of
changes since the previous version, 2.69, as summarized by the NEWS
file.
Unfortunately, we were not able to maintain perfect backward
compatibility with existing Autoconf scripts. Caution is advised when
upgrading. The list of changes, below, includes detailed explanations
and advice for all of the compatibility problems we know about.
Please report bugs and problems with this release to the Savannah bug
tracker:
https://savannah.gnu.org/support/?func=additem&group=autoconf
Please also send general comments and feedback to <autoconf@gnu.org>.
https://lists.gnu.org/archive/html/autoconf/2020-12/msg00002.html
To: info-gnu@gnu.org, autoconf@gnu.org
Subject: autoconf-2.70 released [stable]
Message-Id: <4Cr8xf5THLzcbc@panix1.panix.com>
Date: Tue, 8 Dec 2020 14:14:30 -0500 (EST)
From: Zack Weinberg <zackw@panix.com>
We are pleased to announce stable release 2.70 of GNU Autoconf.
This release includes eight years of development work since the
previous release, 2.69. Noteworthy changes include support for the
2011 revisions of the C and C++ standards, support for reproducible
builds, improved support for cross-compilation, improved compatibility
with current compilers and shell utilities, more efficient generated
shell code, and many bug fixes. See below for a detailed list of
changes since the previous version, 2.69, as summarized by the NEWS
file.
Unfortunately, we were not able to maintain perfect backward
compatibility with existing Autoconf scripts. Caution is advised when
upgrading. The list of changes, below, includes detailed explanations
and advice for all of the compatibility problems we know about.
Please report bugs and problems with this release to the Savannah bug
tracker:
https://savannah.gnu.org/support/?func=additem&group=autoconf
Please also send general comments and feedback to <autoconf@gnu.org>.
2021/08/29(日) 23:18:19.04
もはや追いかける者もいなくなったか。
https://lists.gnu.org/archive/html/autoconf/2021-01/msg00126.html
From: Zack Weinberg
Subject: autoconf-2.71 released [stable]
Date: Thu, 28 Jan 2021 17:49:17 -0500 (EST)
We are pleased to announce stable release 2.71 of Autoconf.
2.71 is a bugfix release, correcting several important compatibility
problems and regressions discovered since the release of 2.70. There
are no new features. Upgrading is recommended for all users of 2.70.
Users of 2.69 or earlier should proceed with caution; please consult
the NEWS file and/or the release announcement for 2.70 for details.
Here are the compressed sources:
https://ftpmirror.gnu.org/autoconf/autoconf-2.71.tar.gz (2.0MB)
https://ftpmirror.gnu.org/autoconf/autoconf-2.71.tar.xz (1.3MB)
Here are the GPG detached signatures[*]:
https://ftpmirror.gnu.org/autoconf/autoconf-2.71.tar.gz.sig
https://ftpmirror.gnu.org/autoconf/autoconf-2.71.tar.xz.sig
NEWS
* Noteworthy changes in release 2.71 (2021-01-28) [stable]
** Bug fixes, including:
*** Compilers that support C99 but not C2011 are detected correctly.
*** Compatibility improved with clang and Oracle C++.
*** Compatibility restored with automake's rules for regenerating configure.
*** Compatibility restored with old versions of std-gnu11.m4.
https://lists.gnu.org/archive/html/autoconf/2021-01/msg00126.html
From: Zack Weinberg
Subject: autoconf-2.71 released [stable]
Date: Thu, 28 Jan 2021 17:49:17 -0500 (EST)
We are pleased to announce stable release 2.71 of Autoconf.
2.71 is a bugfix release, correcting several important compatibility
problems and regressions discovered since the release of 2.70. There
are no new features. Upgrading is recommended for all users of 2.70.
Users of 2.69 or earlier should proceed with caution; please consult
the NEWS file and/or the release announcement for 2.70 for details.
Here are the compressed sources:
https://ftpmirror.gnu.org/autoconf/autoconf-2.71.tar.gz (2.0MB)
https://ftpmirror.gnu.org/autoconf/autoconf-2.71.tar.xz (1.3MB)
Here are the GPG detached signatures[*]:
https://ftpmirror.gnu.org/autoconf/autoconf-2.71.tar.gz.sig
https://ftpmirror.gnu.org/autoconf/autoconf-2.71.tar.xz.sig
NEWS
* Noteworthy changes in release 2.71 (2021-01-28) [stable]
** Bug fixes, including:
*** Compilers that support C99 but not C2011 are detected correctly.
*** Compatibility improved with clang and Oracle C++.
*** Compatibility restored with automake's rules for regenerating configure.
*** Compatibility restored with old versions of std-gnu11.m4.
2021/08/29(日) 23:24:29.22
Announceメールjもろくに流れなくなったかわいそうなAutomake。
From: Jim Meyering
Subject: [automake-commit] annotated tag v1.16.4 created (now 048bc0d)
Date: Mon, 26 Jul 2021 15:38:41 -0400
meyering pushed a change to annotated tag v1.16.4
in repository automake.
at 048bc0d (tag)
tagging 39c0005a1aadefdace6f2c741f8fd8a84e60f0f1 (commit)
replaces v1.16.3
by Jim Meyering
on Mon Jul 26 12:34:11 2021 -0700
From: Jim Meyering
Subject: [automake-commit] annotated tag v1.16.4 created (now 048bc0d)
Date: Mon, 26 Jul 2021 15:38:41 -0400
meyering pushed a change to annotated tag v1.16.4
in repository automake.
at 048bc0d (tag)
tagging 39c0005a1aadefdace6f2c741f8fd8a84e60f0f1 (commit)
replaces v1.16.3
by Jim Meyering
on Mon Jul 26 12:34:11 2021 -0700
2021/08/29(日) 23:40:02.72
人手が足りていないらしい。
https://www.gnu.org/software/automake/
New volunteers to help maintain Automake are needed. Please help if you can.
https://lists.gnu.org/archive/html/automake/2021-03/msg00018.html
From: Karl Berry
Subject: automake bug fixers/developers needed
Date: Fri, 26 Mar 2021 16:39:04 -0600
For about the last year, I've been the main person applying bug fixes to
(or at least reading bug reports for) Automake. My pace has been quite
slow, but since maintenance was almost completely lacking for some years
before that, I've been doing what I could. Mainly, going through the old
bug reports and dealing with the "easy" ones, besides trying to handle
new ones as best I can. There are still many outstanding bug reports
that I have not even read.
Unfortunately, I am going to have even less time for Automake for the
foreseeable future. I will still do what I can, but it will not be much.
Therefore, if you have some automake/perl/shell/make/etc. development
skill or interest, and are also interested in Automake maintenance
continuing, please volunteer if you can. I recommend starting by looking
at the open bug list:
https://debbugs.gnu.org/cgi/pkgreport.cgi?package=automake#_0_4_4
https://www.gnu.org/software/automake/
New volunteers to help maintain Automake are needed. Please help if you can.
https://lists.gnu.org/archive/html/automake/2021-03/msg00018.html
From: Karl Berry
Subject: automake bug fixers/developers needed
Date: Fri, 26 Mar 2021 16:39:04 -0600
For about the last year, I've been the main person applying bug fixes to
(or at least reading bug reports for) Automake. My pace has been quite
slow, but since maintenance was almost completely lacking for some years
before that, I've been doing what I could. Mainly, going through the old
bug reports and dealing with the "easy" ones, besides trying to handle
new ones as best I can. There are still many outstanding bug reports
that I have not even read.
Unfortunately, I am going to have even less time for Automake for the
foreseeable future. I will still do what I can, but it will not be much.
Therefore, if you have some automake/perl/shell/make/etc. development
skill or interest, and are also interested in Automake maintenance
continuing, please volunteer if you can. I recommend starting by looking
at the open bug list:
https://debbugs.gnu.org/cgi/pkgreport.cgi?package=automake#_0_4_4
259名無しさん@お腹いっぱい。
2022/02/25(金) 12:58:42.23 Autoconf,Automake
260名無しさん@お腹いっぱい。
2024/03/27(水) 20:18:27.93 彼女←隠すならぜんぜんいい
マネージャーはクビだろうな
じゃキンプリはないんじゃないかな
マネージャーはクビだろうな
じゃキンプリはないんじゃないかな
2024/03/27(水) 21:02:56.80
実質賃金だけでも
ニコ生は中抜きがえげつない
そんなん言ってスクエニ辞めて
ニコ生は中抜きがえげつない
そんなん言ってスクエニ辞めて
2024/03/27(水) 21:51:16.15
戦争がしたいなら脱退してくれ
みんなでオッパの帰りを祈りましょう🙏❤
貧乏なのでぇNISA枠でデイトレすればいいのに
みんなでオッパの帰りを祈りましょう🙏❤
貧乏なのでぇNISA枠でデイトレすればいいのに
2024/04/19(金) 20:05:37.16
xzの穴にautoconfの難読度が利用されてしまいましたなあ
レスを投稿する
ニュース
- 「介護に疲れた」と自ら通報 100歳母を殺害容疑で79歳男を逮捕 [東京都] [少考さん★]
- 【文春】元TOKIO・国分太一(51)「女性スタッフ2名への“わいせつ事案”」日テレ事情聴取の全貌が分かった! [Ailuropoda melanoleuca★]
- 【文春】スクープ撮! 超人気ゴルファー・都玲華(21) “30歳上”石井忍コーチ(51)と路上レッスン禁断愛 [冬月記者★]
- 【山上裁判】安倍氏が狙わた理由 旧統一教会の関係者が「安倍氏は『われわれの味方』」と宣伝していた [1ゲットロボ★]
- 「地上波で見たいね」…大谷翔平「出場表明」WBC…ネットフリックス「独占放映」に「モーニングショー」浜田敬子氏が願い [muffin★]
- トランプ米大統領声明「高市首相は非常に賢く、非常に強い。素晴らしい指導者になるだろう」「私は素晴らしい関係を築いている」 [お断り★]
- ひるおび「国連の常任理事国は中華民国。中華人民共和国は中華民国を正式に引き継いでない」高市 [931948549]
- 高市早苗、ネトウヨを裏切るwwwwwww「すまん、外国人の不動産規制やっぱ無理だわ」 [246620176]
- 【文春砲】国分太一降板の原因は女性スタッフへのわいせつ [579392623]
- ネトウヨ日本人のムスリムヘイト、止まらない。モスク建設予定地に豚の糞が投げ込まれる [165981677]
- トランプ高市との異例の電話会談わずか25分だけ通訳入れたら実質10分程度。やはり一方的にぶちまけ怒りのガチャ切りだった模様 [709039863]
- 【高市悲報】地方人「35歳メーカー勤務で年収650万円」東京派遣女子「25歳で派遣事務で年収600万円wまだ地方で人生消耗してるの?」 [786648259]
