721856ff24
A PostgreSQL release tarball contains a number of prebuilt files, in particular files produced by bison, flex, perl, and well as html and man documentation. We have done this consistent with established practice at the time to not require these tools for building from a tarball. Some of these tools were hard to get, or get the right version of, from time to time, and shipping the prebuilt output was a convenience to users. Now this has at least two problems: One, we have to make the build system(s) work in two modes: Building from a git checkout and building from a tarball. This is pretty complicated, but it works so far for autoconf/make. It does not currently work for meson; you can currently only build with meson from a git checkout. Making meson builds work from a tarball seems very difficult or impossible. One particular problem is that since meson requires a separate build directory, we cannot make the build update files like gram.h in the source tree. So if you were to build from a tarball and update gram.y, you will have a gram.h in the source tree and one in the build tree, but the way things work is that the compiler will always use the one in the source tree. So you cannot, for example, make any gram.y changes when building from a tarball. This seems impossible to fix in a non-horrible way. Second, there is increased interest nowadays in precisely tracking the origin of software. We can reasonably track contributions into the git tree, and users can reasonably track the path from a tarball to packages and downloads and installs. But what happens between the git tree and the tarball is obscure and in some cases non-reproducible. The solution for both of these issues is to get rid of the step that adds prebuilt files to the tarball. The tarball now only contains what is in the git tree (*). Getting the additional build dependencies is no longer a problem nowadays, and the complications to keep these dual build modes working are significant. And of course we want to get the meson build system working universally. This commit removes the make distprep target altogether. The make dist target continues to do its job, it just doesn't call distprep anymore. (*) - The tarball also contains the INSTALL file that is built at make dist time, but not by distprep. This is unchanged for now. The make maintainer-clean target, whose job it is to remove the prebuilt files in addition to what make distclean does, is now just an alias to make distprep. (In practice, it is probably obsolete given that git clean is available.) The following programs are now hard build requirements in configure (they were already required by meson.build): - bison - flex - perl Reviewed-by: Michael Paquier <michael@paquier.xyz> Reviewed-by: Andres Freund <andres@anarazel.de> Discussion: https://www.postgresql.org/message-id/flat/e07408d9-e5f2-d9fd-5672-f53354e9305e@eisentraut.org |
||
|---|---|---|
| .. | ||
| cyrillic_and_mic | ||
| euc2004_sjis2004 | ||
| euc_cn_and_mic | ||
| euc_jp_and_sjis | ||
| euc_kr_and_mic | ||
| euc_tw_and_big5 | ||
| latin2_and_win1250 | ||
| latin_and_mic | ||
| utf8_and_big5 | ||
| utf8_and_cyrillic | ||
| utf8_and_euc2004 | ||
| utf8_and_euc_cn | ||
| utf8_and_euc_jp | ||
| utf8_and_euc_kr | ||
| utf8_and_euc_tw | ||
| utf8_and_gb18030 | ||
| utf8_and_gbk | ||
| utf8_and_iso8859 | ||
| utf8_and_iso8859_1 | ||
| utf8_and_johab | ||
| utf8_and_sjis | ||
| utf8_and_sjis2004 | ||
| utf8_and_uhc | ||
| utf8_and_win | ||
| Makefile | ||
| README.euc_jp | ||
| meson.build | ||
| proc.mk | ||
README.euc_jp
新しいエンコーディング変換関数の追加方法 2006/04/15 Tatsuo Ishii はじめに PostgreSQLには，データベースとフロントエンドのエンコーディングが異なる ときに，自動的にエンコーディングの変換を行う機能があります．このディレ クトリには，そのときに使われる関数が登録されています．これらの関数はユー ザ定義C関数として，initdbの中で登録されます．具体的には， /usr/local/pgsql/share/conversion_create.sql の中で登録されます(このファ イルはこのディレクトリでmakeしたときに自動生成されます)． また，これらの関数はconvert()関数からも呼び出されることもあります． このREADMEでは，C関数を定義する方法と，それをMakefileなどに追加する方 法を説明します． o C関数の呼び出し形式 エンコーディング変換関数の呼び出し形式は次のようになります． conv_proc( INTEGER, -- source encoding id INTEGER, -- destination encoding id CSTRING, -- source string (null terminated C string) INTERNAL, -- destination string (null terminated C string) INTEGER -- source string length ) returns VOID; 唯一の出力引数は4番目のdestination stringです．ユーザ定義関数は必要 なメモリをpallocし，そこに変換結果をNULLターミネートされたC文字列と して出力しなければなりません．また，適切な大きさのメモリを確保するの は，このC関数の責任です．というのは，一般に変換された文字列の長さは ソース文字列の長さ(5番目の引数で指定されます．単位はNULLターミネート を含まないバイト数です)とは一致しないからです． エンコーディングIDはinclude/mb/pg_wchar.hのtypedef enum pg_encで定義 されています． o 関数の登録とコンパイル 作ったC関数はサブディレクトリを作り，その中に納めます．その中に Makefileも必要になりますが，他のディレクトリにあるMakefileを参考にす れば簡単に作成できるでしょう． 次にメインのMakefile(このファイルが置いてある同じディレクトリにあり ます)に関数に関する記述を追加します． (1) DIRS=の後にサブディレクトリ名を追加します． (2) @set \ で始まる項目に記述を追加します．1関数につき1行の追加が必要 です． コンバージョンの名前 ソースエンコーディング名 デスティネーションエンコーディング名 関数名 オブジェクトファイル名 を1行の中にスペースで区切って追加します． o テスト 以上が終わったら，このファイルがあるディレクトリでmakeし，すべてがう まくいくことを確認します．特に，create_conversion.sqlがちゃんとした 内容になっているかどうか確認しましょう．良さそうだったら，テスト用に 新しいデータベースを作り，そこでこのスクリプトを実行します． $ psql -e -f create_conversion.sql test これも正常だったら，最後にregression test suiteにテスト項目を追加し てください．具体的には，src/test/regress/sql/conversion.sqlに追加し， regression testを行います． o 注意事項 デフォルトのエンコーディング変換として使用できるためには，ソースエン コーディングとデスティネーションエンコーディングの間で双方向の変換が できることが必要です．すなわち，あるエンコーディングのペアに付き，2 個の関数の作成が必要です．これらの関数は別々のサブディレクトリに登録 しても良いですが，通常は一つのソースファイル中に2個の関数を書くこと が多いでしょう．