运行 sudo make 与 make 时如何使用 .makerc 文件?
我正在 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 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
sudo -E
保护环境。根据您的操作系统和版本,这在某些时候是默认设置,但可能不再是默认设置。所以尝试一下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 trysudo
不应更改当前用户环境,因此所有变量和对 homedir 文件的访问都会保留。也许你应该定义一个像setenv.sh
这样的文件:并在你的构建 shell 中获取它:
或者你可以将它放入你的
.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 likesetenv.sh
:And source it in your build shell:
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?'终于在 Google 上找到了正确的关键字:“sudo 导出环境变量”...
这最终让我找到了
/etc/sudoers
文件,该文件需要使用visudo 以 root 身份进行编辑
命令。因此,首先,
~/.bash_profile
文件中需要两行:需要
vi
程序作为编辑器(mate -w
没有由于某种原因不想工作),因此visudo
的精确命令是:在环境重置后添加两行:
最后重新启动终端,一切顺利。
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 thevisudo
command.So, first, two lines are needed in the
~/.bash_profile
file:The
vi
program is needed as an editor (mate -w
didn't want to work for some reason), so the precise command forvisudo
is:Add two lines after the environment reset:
Finally restart the terminal, and good to go.
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 副本):我希望该提示有所帮助(在
bash(1)
上使用tcsh(1)
救了我数以百万计的时间的挫折和调试时间......历史才是真正赢得我的东西,但那是一个不同的故事)。正是这样的东西使tcsh(1)
成为我与系统交互的首选 shell(必要时我仍然在sh
中编写脚本)。至于你的具体情况:
或者因为你在使用 MacPorts 的 mac 上(我的本机开发环境):
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):I hope the tip helps (using
tcsh(1)
overbash(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 makestcsh(1)
my preferred shell for interacting with systems (I still script insh
where necessary).As for your specific situation:
or since you're on a mac using MacPorts (my native dev env):