运行 sudo make 与 make 时如何使用 .makerc 文件?

发布于 2024-11-11 13:57:11 字数 2367 浏览 2 评论 0原文

我正在 Snow Leopard 安装上编译几个 Postgres 扩展(使用 MacPorts 安装的 Postgres)。这通常需要与 make 命令一起传递两个变量,例如:

sudo make install USE_PGXS=1 PGUSER=postgres

至少可以说,我的 C 有点生疏,我在 google 上搜索无果,希望找到一种不需要传递上述两个变量的方法变量。

我似乎做了一些正确的事情...我当前的 ~/.makerc 文件包含以下内容:

$ cat ~/.makerc 
USE_PGXS=1
PGUSER=postgres

这解决了运行 make installcheck 时的问题,但在没有 sudo 的情况下运行它> 通常意味着在实际 make 过程中出现权限问题,并且当我运行 sudo make installcheck 时,不会读取 .makerc 。我以 root 身份登录,并在 /var/root 中放置了指向上述文件的符号链接,但无济于事。

可以说,我可以诉诸以 root 身份登录来完成所有这些操作。然而,我很想知道我是否忽略了一些事情。在运行 sudo make 而不是 make 时,是否无法使用 .makerc 文件?


编辑:评论日志,在最初的建议之后:

DB:~/pgdevel/kmeans-postgresql $ export USE_PGXS=1
DB:~/pgdevel/kmeans-postgresql $ export PGUSER=postrgess

这失败了,因为它使 makefile 假设 kmeans-postgresql 位于 postgres/contrib 中(这就是 USE_PGXS 的含义,并且将其放在 postgres/contrib 中也会失败,因为它是使用安装的MacPorts):

DB:~/pgdevel/kmeans-postgresql $ sudo make

Makefile:34: ../../src/Makefile.global: No such file or directory
Makefile:35: /contrib/contrib-global.mk: No such file or directory
make: *** No rule to make target `/contrib/contrib-global.mk'.  Stop.

这成功了(即使没有导出):

DB:~/pgdevel/kmeans-postgresql $ make

sed 's,MODULE_PATHNAME,$libdir/kmeans,g' kmeans.sql.in >kmeans.sql
cp kmeans.sql kmeans--1.0.0.sql
/usr/bin/gcc-4.2 -pipe -O2 -arch x86_64 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wformat-security -fno-strict-aliasing -fwrapv  -I. -I. -I/opt/local/include/postgresql91/server -I/opt/local/include/postgresql91/internal -I/opt/local/include -I/opt/local/include/ossp -I/opt/local/include/libxml2  -I/opt/local/include  -c -o kmeans.o kmeans.c
[some warnings...]
/usr/bin/gcc-4.2 -pipe -O2 -arch x86_64 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wformat-security -fno-strict-aliasing -fwrapv  -L/opt/local/lib/postgresql91 -L/opt/local/lib -arch x86_64 -L/opt/local/lib  -L/opt/local/lib -Wl,-dead_strip_dylibs   -bundle -bundle_loader /opt/local/lib/postgresql91/bin/postgres -o kmeans.so kmeans.o
rm kmeans.o

PS:我正在重新添加 OSX 和 PostgreSQL 标签,因为虽然与 PostgreSQL 不严格相关,但我希望 MacOSX 上的另一个 PostgreSQL 用户可能知道解决方法。

I'm in the process of compiling a couple of Postgres extensions on a Snow Leopard installation (Postgres installed using MacPorts). This frequently requires two variables to be passed along with the make command, e.g.:

sudo make install USE_PGXS=1 PGUSER=postgres

My C is a bit rusty to say the least, and I've googled around to no avail in hopes of finding a means to not need to pass the above two variables.

I seem to have done a few things right... My current ~/.makerc file contains the following:

$ cat ~/.makerc 
USE_PGXS=1
PGUSER=postgres

This fixed the issue when running make installcheck, but running this without sudo frequently means permission problems down the road during the actual make process, and the .makerc isn't being read when I run sudo make installcheck. I logged in as root and placed a symbolic link in /var/root to the above file, to no avail.

I could arguably resort to doing all of this logged in as root. I'm curious to know if I might have overlooked something, however. Is there no means to make use of a .makerc file when running sudo make instead of make?


Edit: commented log, after the initial suggestion:

DB:~/pgdevel/kmeans-postgresql $ export USE_PGXS=1
DB:~/pgdevel/kmeans-postgresql $ export PGUSER=postrgess

This fails, because it makes the makefile assume that kmeans-postgresql is in postgres/contrib (which is what USE_PGXS is about, and placing it in postgres/contrib fails too because it was installed using MacPorts):

DB:~/pgdevel/kmeans-postgresql $ sudo make

Makefile:34: ../../src/Makefile.global: No such file or directory
Makefile:35: /contrib/contrib-global.mk: No such file or directory
make: *** No rule to make target `/contrib/contrib-global.mk'.  Stop.

This succeeds (even without the export):

DB:~/pgdevel/kmeans-postgresql $ make

sed 's,MODULE_PATHNAME,$libdir/kmeans,g' kmeans.sql.in >kmeans.sql
cp kmeans.sql kmeans--1.0.0.sql
/usr/bin/gcc-4.2 -pipe -O2 -arch x86_64 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wformat-security -fno-strict-aliasing -fwrapv  -I. -I. -I/opt/local/include/postgresql91/server -I/opt/local/include/postgresql91/internal -I/opt/local/include -I/opt/local/include/ossp -I/opt/local/include/libxml2  -I/opt/local/include  -c -o kmeans.o kmeans.c
[some warnings...]
/usr/bin/gcc-4.2 -pipe -O2 -arch x86_64 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wformat-security -fno-strict-aliasing -fwrapv  -L/opt/local/lib/postgresql91 -L/opt/local/lib -arch x86_64 -L/opt/local/lib  -L/opt/local/lib -Wl,-dead_strip_dylibs   -bundle -bundle_loader /opt/local/lib/postgresql91/bin/postgres -o kmeans.so kmeans.o
rm kmeans.o

PS: I'm re-adding the OSX and PostgreSQL tags because, while not strictly PostgreSQL related, I'm hoping another PostgreSQL user on MacOSX might know the workaround.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

诗化ㄋ丶相逢 2024-11-18 13:57:11

sudo -E 保护环境。根据您的操作系统和版本,这在某些时候是默认设置,但可能不再是默认设置。所以尝试一下

sudo -E make install

sudo -E preserves the environment. Depending on your operating system and version, this was the default at some point, but might not be anymore. So try

sudo -E make install
指尖凝香 2024-11-18 13:57:11

sudo 不应更改当前用户环境,因此所有变量和对 homedir 文件的访问都会保留。也许你应该定义一个像 setenv.sh 这样的文件:

export USE_PGXS=1
export PGUSER=postrgess

并在你的构建 shell 中获取它:

$ . setenv.sh

或者你可以将它放入你的 .bashrc 中,但这将包含在所有你的 shell,在未来的某个时候你可能会感到困惑“为什么这个该死的 Postgress 会这样编译?”

The sudo shouldn't change current user environment, so all variables and access to homedir files are preserved. Maybe you should define a file like setenv.sh:

export USE_PGXS=1
export PGUSER=postrgess

And source it in your build shell:

$ . setenv.sh

Or you can put it into your .bashrc, but that will be included in all your shells and in some time in the future you can get confused 'why this dammed Postgress gets compiled like that?'

北笙凉宸 2024-11-18 13:57:11

终于在 Google 上找到了正确的关键字:“sudo 导出环境变量”...

这最终让我找到了 /etc/sudoers 文件,该文件需要使用 visudo 以 root 身份进行编辑 命令。

因此,首先,~/.bash_profile 文件中需要两行:

export PGUSER=postgres
export USE_PGXS=1

需要 vi 程序作为编辑器(mate -w 没有由于某种原因不想工作),因此 visudo 的精确命令是:

env EDITOR=vi sudo visudo

在环境重置后添加两行:

Defaults        env_keep += "PGUSER"
Defaults        env_keep += "USE_PGXS"

最后重新启动终端,一切顺利。

Finally found the right keywords to Google: "sudo export environment variable"...

This eventually led me to identify the /etc/sudoers file, which needs to be edited as root using the visudo command.

So, first, two lines are needed in the ~/.bash_profile file:

export PGUSER=postgres
export USE_PGXS=1

The vi program is needed as an editor (mate -w didn't want to work for some reason), so the precise command for visudo is:

env EDITOR=vi sudo visudo

Add two lines after the environment reset:

Defaults        env_keep += "PGUSER"
Defaults        env_keep += "USE_PGXS"

Finally restart the terminal, and good to go.

囚我心虐我身 2024-11-18 13:57:11

Denis,我几乎完全出于这个原因使用 tcsh(1)。不同的工具、项目、工作环境等都需要不同的工具链,因此需要不同的环境变量。然而,这种不同的上下文几乎总是受到您所在目录的限制。

以下是我的 .cshrc 文件(第 100-116 行)中的内容:

https://github.com/sean-/cshrc/blob/master/.cshrc#L100

然后我在文件系统中乱扔这样的东西:

https:/ /github.com/sean-/flask-骨骼/blob/master/.enter.tcsh

或此:

https://github.com/sean-/Boost.Examples/blob/master/.enter.tcsh#L1

在后一个示例中我想要为了支持分布式 .enter.tcsh 文件中的站点本地设置,我添加了对 .local.tcsh 约定的支持,然后我可以提供自己的设置(在在这种情况下,我使用了不在标准位置的 boost 副本):

# My .local.tcsh file for the Boost.Examples project referenced above.
if ( ${?BOOST_INCDIR} == "0" ) then
  setenv BOOST_INCDIR $HOME/src/foo/obj/contrib-Darwin-i386/include
  printf '[INFO] Setting BOOST_INCDIR environment variable to %s\n' ${BOOST_INCDIR}
endif

if ( ${?BOOST_LIBDIR} == "0" ) then
  setenv BOOST_LIBDIR $HOME/src/foo/obj/contrib-Darwin-i386/lib
  printf '[INFO] Setting BOOST_LIBDIR environment variable to %s\n' ${BOOST_LIBDIR}
endif

if ( ${?DYLD_FALLBACK_LIBRARY_PATH} == "0" ) then
  setenv DYLD_FALLBACK_LIBRARY_PATH $HOME/src/foo/obj/contrib-Darwin-i386/lib
  printf '[INFO] Setting DYLD_FALLBACK_LIBRARY_PATH environment variable to %s\n' ${DYLD_FALLBACK_LIBRARY_PATH}
endif

我希望该提示有所帮助(在 bash(1) 上使用 tcsh(1) 救了我数以百万计的时间的挫折和调试时间......历史才是真正赢得我的东西,但那是一个不同的故事)。正是这样的东西使 tcsh(1) 成为我与系统交互的首选 shell(必要时我仍然在 sh 中编写脚本)。

至于你的具体情况:

sudo env PGUSER=postgres USE_PGXS=1 make install

或者因为你在使用 MacPorts 的 mac 上(我的本机开发环境):

sudo env PGUSER=postgres USE_PGXS=1 PATH=/opt/local/lib/postgresql91/bin:${PATH} make install

Denis, I use tcsh(1) nearly exclusively for exactly this reason. Different tools, projects, work environments, etc, all require different toolchains and therefore different environment variables. This different context, however, is almost always bounded by the directory that you're in.

Here's what I have in my .cshrc file (lines 100-116):

https://github.com/sean-/cshrc/blob/master/.cshrc#L100

And then I litter my file system with things like this:

https://github.com/sean-/flask-skeleton/blob/master/.enter.tcsh

or this:

https://github.com/sean-/Boost.Examples/blob/master/.enter.tcsh#L1

In the latter example where I want to support site-local settings in a distributed .enter.tcsh file, I add support for the convention of .local.tcsh and then I can provide my own settings (in this case, I use a copy of boost that's not in the standard location):

# My .local.tcsh file for the Boost.Examples project referenced above.
if ( ${?BOOST_INCDIR} == "0" ) then
  setenv BOOST_INCDIR $HOME/src/foo/obj/contrib-Darwin-i386/include
  printf '[INFO] Setting BOOST_INCDIR environment variable to %s\n' ${BOOST_INCDIR}
endif

if ( ${?BOOST_LIBDIR} == "0" ) then
  setenv BOOST_LIBDIR $HOME/src/foo/obj/contrib-Darwin-i386/lib
  printf '[INFO] Setting BOOST_LIBDIR environment variable to %s\n' ${BOOST_LIBDIR}
endif

if ( ${?DYLD_FALLBACK_LIBRARY_PATH} == "0" ) then
  setenv DYLD_FALLBACK_LIBRARY_PATH $HOME/src/foo/obj/contrib-Darwin-i386/lib
  printf '[INFO] Setting DYLD_FALLBACK_LIBRARY_PATH environment variable to %s\n' ${DYLD_FALLBACK_LIBRARY_PATH}
endif

I hope the tip helps (using tcsh(1) over bash(1) has saved me gazillions of hours of frustration and debugging time... the history is what really won me, but that's a different story). It's stuff like this that makes tcsh(1) my preferred shell for interacting with systems (I still script in sh where necessary).

As for your specific situation:

sudo env PGUSER=postgres USE_PGXS=1 make install

or since you're on a mac using MacPorts (my native dev env):

sudo env PGUSER=postgres USE_PGXS=1 PATH=/opt/local/lib/postgresql91/bin:${PATH} make install
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文