这里有人对 scons 感兴趣吗？

[li wang]

hi~ 诸位：

我在这里看到的好多贴都是讨论用 python 实现 WebApp 的，其实 python 还有许多其它用途。scons 就是我很喜欢的一个，不知这里有其它喜欢 scons 并有一定实践经验的人吗？

Charles Wang

[huliuhe]

了解过，可是一直没有使用过。 很多项目是make，再就是perl脚本。搞懂编译和搞懂系统一样复杂。痛苦。希望未来的项目scons能多点，据说ti的新平台就是由scons构建的

2008/9/8 li wang <charles...@gmail.com>

[Zoom.Quiet]

2008/9/8 li wang <charles...@gmail.com>:

> 我在这里看到的好多贴都是讨论用 python 实现 WebApp 的，其实 python 还有许多其它用途。scons
> 就是我很喜欢的一个，不知这里有其它喜欢 scons 并有一定实践经验的人吗？
>

没有体验过，分享一下具体的？

> Charles Wang

--

http://zoomquiet.org'''
过程改进乃是催生可促生靠谱的人的组织!
PE keeps evolving organizations which promoting people be good!'''

[Border]

第一次听说，能不能简单的说说心得，比如比make，automake, autoconf, ant 之类的有什么优势。

2008/9/8 Zoom. Quiet <zoom....@gmail.com>

2008/9/8 li wang <charles...@gmail.com>:

> 我在这里看到的好多贴都是讨论用 python 实现 WebApp 的，其实 python 还有许多其它用途。scons
> 就是我很喜欢的一个，不知这里有其它喜欢 scons 并有一定实践经验的人吗？
>

没有体验过，分享一下具体的？

> Charles Wang

--
Bian Jiang
Blog: http://www.b0rder.com/
Mail: borderj {at} gmail.com

[Gang Chen]

2008/9/8 li wang <charles...@gmail.com>:

> hi~ 诸位：
>
> 我在这里看到的好多贴都是讨论用 python 实现 WebApp 的，其实 python 还有许多其它用途。scons
> 就是我很喜欢的一个，不知这里有其它喜欢 scons 并有一定实践经验的人吗？

以前编译XMMS2的时候接触到，后来想把它应用到Java项目的构建上，但对构建时生成的文件支持不是太好所以就没有用下去。

--
If it makes you happy, it can't be that bad.

[Charles Wang]

呵呵，看来这个软件在国内接触的人确实不多。我注意BuildSystem是相当早了，最早在1999年
的时候发狠把当时的autoconf、automake手册给翻译成中文了。在相当长的一段时间之内，个人
感觉autoconf/automake/make的组合是可以满足基本需求的。所以当时还进一步翻译了GNU 软件
发行惯例。这些译文大家都可以在 http://www.linuxforum.net/books/index.php 看到。

大约在2001年吧，我开始在Linux下做嵌入式开发。此前虽然发现了一些autoconf/automake/make
的问题，但还没到痛苦的地步。因为嵌入式Linux系统，要多出交叉编译和系统生成两大块任务，
用autoconf/automake/make就开始感受到限制了。当然那时候还不知道什么其他的创建工具的存在，
所以就仿照 kernel build system 的方法，用make来做。其间也确实遭受了不少痛苦经历，呵呵。

后来在2003年终于忍无可忍，开始寻找新工具。找来找去，由于偶然或非偶然的机会，发现了scons。
用过之后就再也没改了。那时候scons的版本还比较低，不过已经相当好用了。这里列举一下区别吧：

* 对交叉编译的支持：
autoconf/automake/make 把所有的变量名都放在一个命名空间之中，这使得我们只能用不同的变量
名来区分用于不同体系的编译宏。例如，在kernel build system里面，CC这个变量是用于编译目标
体系结构的代码的，而HOSTCC则是用于编译当前体系结构的代码的。所有其它变量都必须通过加前缀
的方式加以区分；
scons 提供 Environment 对象，每个对象都是一个编译变量容器。所以针对不同的目标体系结构，
在scons中可以存在大量的 Environment 对象。例如像 kernel build system 那样，可以分别为目标
体系结构和当前体系结构定义两个明确区分的 Environment 对象。而不会造成任何混淆；
* 如何确定一个文件是否改变：
make 是使用文件的timestampe来检查文件是否已经被改变了。可是这就要求当前系统具有正确的
系统时钟。这一问题在使用CVS时会更加突出一些。因为CVS会纪录提交时间，加入CVS服务器的系统
时钟超前或者落后，那么肯定会造成混乱。还有一个问题就是如果通过CVS取回以前的版本，那么它
会把这个文件的时间设置成该文件提交的时间。如果再以时间戳为准判断文件是否改变，就会出现
把改变了的文件误认为没有改变的文件的情况了。
scons 以文件内容的校验和为标志来确认文件是否被改变。以校验和为标志可以脱离对系统时间的
依赖，当然付出的代价是速度比时间戳慢一点。不过通过获得精确的依赖性关系所节省的时间，要比
依赖关系不全而被迫使用 make clean 要短许多吧。同时scons也支持使用时间戳作为判断依据。
* 是否参考命令行的变化：
make 在检查依赖性的时候，并不检查命令行的变化。可是命令行的变化却对目标文件的生成有着
很大的影响。例如，在命令行里面，加-g或不加-g、加-DNDEBUG或不加-DNDEBUG。
scons 把命令行的变化考虑在内，如果命令行发生变化了，那么目标也必须重新编译。
* 是否拥有全局依赖性信息：
autoconf/automake/make 组合，以递归的方式使用 make。但是在这样的情况下，会出现问题：
假定源代码目录结构为根目录下有： lib、src、tools 几个目录，其中均还有源代码。那么如果在
src 目录中执行 make，lib 目录中的文件即时发生了变化，也不会重新编译lib中的源代码。当然
这是由于递归方式使用make导致make没有获得完整的依赖关系造成的。具体参见：
http://aegis.sourceforge.net/auug97.pdf
scons 则是每次都完整地运行整个buildsystem代码，以获得完整的依赖关系。它不会出现上述缺陷。
* 编程语言：
autoconf/automake/make 组合，混杂了 m4、make、shell 等众多不同的脚本语言，没有一样是常用的。
scons，纯python。由于python是全功能流行的强攻能语言，这使得组建编译系统的能力和便捷性大大增强。
* 跨平台：
autoconf/automake/make 在 Windows 下，必须在mingw之类的模拟环境中运行。这是因为autoconf生成的
configure脚本使用了许多shell命令，这些都要由环境来提供。而且不同系统中的命令集合有可能不同，同一
命令的具体功能也可能不同。同时，make存在众多不同版本。为了弥补这些似是而非的区别，导致了
autoconf/automake的高度复杂性。
scons，支持跨平台，除了python 之外没有其它依赖。在Windows下即可以在mingw中运行，又可以在普通
Windows命令行中运行。
* 复杂度：
autoconf/automake/make 组合，必须编写 configure.ac、Makefile.am。而最终使用的
configure 脚本和
Makefile 可能长达数万行，我本人就曾被这些几万行的东西搞得天昏地暗。打开一次都折寿。
scons，脚本相当简单。在scons内部就可以自动完成各种自动依赖性的扫描。
* 对代码生成、信息传播的支持：
我们知道，一项信息如果只存在于一个地方是最好的。如果存在于两个地方就可能因为不一致而造成BUG。
例如说，屏幕的尺寸。但是需要信息的地方可能不止一个，这时候就需要我们把仅存在于一处的信息传播
到所有需要它的地方。这种传播可能发生在运行时，也可能发生在编译时。发生在编译时的传播适用于在
软件的特定版本中不变的常量，优点是不必在运行时付出任何代价。一般而言比较简单的这类传播是
通过宏定义实现的，但更为复杂的就会涉及到源代码的生成。
autoconf/automake/make 只能使用shell脚本生成，不能实现过于复杂的处理
scons 可以用python 函数实现任意复杂度的处理。例如我曾经在我的scons脚本里面，调用 subversion-python
的模块，自动把svn版本号潜入到源代码中。

上面列举的区别，有些是质的区别，有些是量的区别。但是无论如何，以较低的代价获得较好的效果，使得
我们能够把更多的注意力放到完成BuildSystem的功能上去。所以我认为即使仅仅是量变、简化也有意义。

呵呵，不过我发现长久以来似乎国内无人注意到这一软件。我想python爱好者当中总会有人感兴趣吧？
在2003年我曾经使用scons开发过一个项目。连接是：http://trac.magiclinux.org/magicinstaller/
wiki/MagicInstaller
不过那时候对scons的了解还很肤浅，没能做到一条命令生成整个嵌入式目标文件系统。现在已经是piece of cake了。

[Charles Wang]

哦，我是从来没用过Java，所以没接触到你的问题。不过这种新生的软件有细节问题也不奇怪，前些天我还遇到
在Windows下路径解析的问题呢，对此我主要是看主流的。你可以把你的具体问题说说，看看我是否能帮你，呵呵。

使用scons以后，由于它的依赖性关系非常完整，我基本上不必再运行 scons -c (对应于 make clean)了。

On 9月9日, 上午9时09分, "Gang Chen" <gon...@gmail.com> wrote:
> 2008/9/8 li wang <charlesw123...@gmail.com>:

[Gang Chen]

2008/9/9 Charles Wang <charles...@gmail.com>:

> 哦，我是从来没用过Java，所以没接触到你的问题。不过这种新生的软件有细节问题也不奇怪，前些天我还遇到
> 在Windows下路径解析的问题呢，对此我主要是看主流的。你可以把你的具体问题说说，看看我是否能帮你，呵呵。
>
> 使用scons以后，由于它的依赖性关系非常完整，我基本上不必再运行 scons -c (对应于 make clean)了。

scons的自动发现源文件依赖＋手工植入源文件依赖，可以为编写构建脚本剩下不少时间。

我的情况比较特殊，举一个EJB的例子：我提供的源文件为FooBean.java；scons需要调用工具生成Foo.java，FooLocal.java，FooHome.java，FooLocalHome.java；然后scons调用javac将这5个文件编译成.class。这个例子应该和yacc，ylex生成代码的例子是一样的。

个人感觉scons还是比较适合C/C++类型的项目使用。

@Charles Wang
不用在上面的问题上太花时间，我现在还是回归到ANT了。

[刘鑫]

这种东西只要能走命令行，Python很容易就搞定的，另外yacc之类的工具好像有python库实现，在art of programming unix看到，没有太注意过。

2008/9/9 Gang Chen <gon...@gmail.com>

--
站着说话不腰疼，于是中国人民都站起来
说话了
……

劉鑫
March.Liu

[Gang Chen]

2008/9/9 刘鑫 <marc...@gmail.com>:

> 这种东西只要能走命令行，Python很容易就搞定的，另外yacc之类的工具好像有python库实现，在art of programming
> unix看到，没有太注意过。
>
> 2008/9/9 Gang Chen <gon...@gmail.com>

>> 我的情况比较特殊，举一个EJB的例子：我提供的源文件为FooBean.java；scons需要调用工具生成Foo.java，FooLocal.java，FooHome.java，FooLocalHome.java；然后scons调用javac将这5个文件编译成.class。这个例子应该和yacc，ylex生成代码的例子是一样的。

问题就在FooBean.java出现在javac的命令行上，但是其余几个生成出来的.java文件没有出现在javac命令行上。scons在为javac收集文件时4个生成的.java文件还没有出现，导致最终不能javac这几个文件。

[Linker]

2008/9/8 li wang <charles...@gmail.com>

hi~ 诸位：

我在这里看到的好多贴都是讨论用 python 实现 WebApp 的，其实 python 还有许多其它用途。scons 就是我很喜欢的一个，不知这里有其它喜欢 scons 并有一定实践经验的人吗？

我用CMake,感觉很好.

Scons可能比较慢.

 

Charles Wang

--
Linker M Lin
linker...@gmail.com

[刘鑫]

嗯，看起来是要专为这几个文件写一个python脚本，如果从编译工具的角度讲，这个实现方法太python化了，不够make，但是这个问题又太java化，恐怕scons不会单独为它写一个支持吧：）。

2008/9/9 Gang Chen <gon...@gmail.com>

[刘鑫]

scons我用过，著名的blender 3d就是用scons编译的，其实也没有明显的慢，因为编译的时间要远远高于脚本执行的时间。

2008/9/9 Linker <linker...@gmail.com>

[Gang Chen]

2008/9/9 刘鑫 <marc...@gmail.com>:

> 嗯，看起来是要专为这几个文件写一个python脚本，如果从编译工具的角度讲，这个实现方法太python化了，不够make，但是这个问题又太java化，恐怕scons不会单独为它写一个支持吧：）。

刚刚去scons主页看了一下，貌似除了1.0。0.9系列走的是够长了。有空下载一份把玩把玩。

[Zoom.Quiet]

2008/9/9 Gang Chen <gon...@gmail.com>:

> 2008/9/9 Charles Wang <charles...@gmail.com>:
>> 哦，我是从来没用过Java，所以没接触到你的问题。不过这种新生的软件有细节问题也不奇怪，前些天我还遇到
>> 在Windows下路径解析的问题呢，对此我主要是看主流的。你可以把你的具体问题说说，看看我是否能帮你，呵呵。
>>
>> 使用scons以后，由于它的依赖性关系非常完整，我基本上不必再运行 scons -c (对应于 make clean)了。
>

非常感谢 Charles Wang 分享的又一 Python 强力应用! 收录 在:
http://wiki.woodpecker.org.cn/moin/PyScons
期望继续积累下去,让理解的人,真正使用起来,,,,

> scons的自动发现源文件依赖＋手工植入源文件依赖，可以为编写构建脚本剩下不少时间。
>
> 我的情况比较特殊，举一个EJB的例子：我提供的源文件为FooBean.java；scons需要调用工具生成Foo.java，FooLocal.java，FooHome.java，FooLocalHome.java；然后scons调用javac将这5个文件编译成.class。这个例子应该和yacc，ylex生成代码的例子是一样的。
>
> 个人感觉scons还是比较适合C/C++类型的项目使用。
>
> @Charles Wang
> 不用在上面的问题上太花时间，我现在还是回归到ANT了。
>

--

http://zoomquiet.org'''

[nEO (a.k.a. gentoo.cn)]

2008/9/8 li wang <charles...@gmail.com>

hi~ 诸位：

我在这里看到的好多贴都是讨论用 python 实现 WebApp 的，其实 python 还有许多其它用途。scons 就是我很喜欢的一个，不知这里有其它喜欢 scons 并有一定实践经验的人吗？

Charles Wang

呵呵,我在用啊
不过KDE抛弃了scons了
--
I'm the one, powered by nEO
-----------------------------------------
http://loveumyriad.72pines.com

[Zhuo Wei]

google 的 chromium 用的也是scons.

2008/9/9 nEO (a.k.a. gentoo.cn) <gentoo.cn@gmail.com>

[Jiahua Huang]

On 9/9/08, 刘鑫 <marc...@gmail.com> wrote:
> scons 我用过，著名的 blender
> 3d 就是用 scons 编译的，其实也没有明显的慢，因为编译的时间要远远高于脚本执行的时间。

第二人生， Google Chrome、skim 都是使用 scons 的

[Jiahua Huang]

On 9/9/08, Jiahua Huang <jhuang...@gmail.com> wrote:
> 第二人生， Google Chrome、skim 都是使用 scons 的
>

scons 的"坏处" 也是依赖较新的 python，
像 skim 的编译使用 scons，在 Ubuntu 等现代 Linux 发行版上完全没有问题，
但是在 Debian 之类守旧陈腐的老古董上， 编译服务器就会出错

[Charles Wang]

你这个问题我以前经历过的，那次我好像是要做自动从网上下载包文件吧。

这里牵涉到一个概念，用久了scons会注意到，它把它的运行过程明确划分成两个阶段：
1、运行所有SConstruct/SConscript，收集到所有的依赖性关系；
2、分析依赖性关系，执行必须执行的操作；
其中对依赖性关系的分析，是由scons自动完成的。
我们写SConstruct/SConscript必须特别注意的一点是，要明确区分那些代码是在第一阶段运行的，
那些代码是第二阶段要执行的动作中运行的。不清楚的话会被搞晕的，呵呵。

所以你说的从 FooBean.java 生成 Foo.java, FooLocal.java ...，其实是在完成某些特定动作
之后，才能够确定的依赖性关系。这就打破了前面所说的两个阶段的划分，scons就不容易处理了。

对于这类问题，我一般都是在第一阶段中调用一个从scons进程，让这个从scons进程去调用你说的
工具去生成 Foo.java、FooLocal.java ..... 这样主scons就可以在第一阶段完成之前获得
FooBean.class 完整的依赖关系列表了。

所以你这个问题跟 .y -> .c -> .o 的过程是不同的，它的依赖性关系是不必通过某些工具来获得，
可以直接写出来的。因此也没必要去调用从scons获得依赖性关系列表了。

根据你的描述，FooBean.java 应该是含有了用于生成FooBean.class的完整信息了的，毕竟Foo.java、
FooLocal.java都是从FooBean.java中生成的啊。那么javac 为什么不能直接从FooBean.java生成
FooBean.class 呢？中间文件难道还可能被修改或者被其他文件所依赖吗？呵呵，我不懂java的啊。

如果没有什么特殊要求，我看可以做一个脚本，实现从FooBean.java到FooBean.class的转换。并
用这个脚本代替 javac，这样就不必调用从scons进程了。

On 9月9日, 上午10时07分, "Gang Chen" <gon...@gmail.com> wrote:
> 2008/9/9 Charles Wang <charlesw123...@gmail.com>:

>
> > 哦，我是从来没用过Java，所以没接触到你的问题。不过这种新生的软件有细节问题也不奇怪，前些天我还遇到
> > 在Windows下路径解析的问题呢，对此我主要是看主流的。你可以把你的具体问题说说，看看我是否能帮你，呵呵。
>
> > 使用scons以后，由于它的依赖性关系非常完整，我基本上不必再运行 scons -c (对应于 make clean)了。
>
> scons的自动发现源文件依赖＋手工植入源文件依赖，可以为编写构建脚本剩下不少时间。
>

> 我的情况比较特殊，举一个EJB的例子：我提供的源文件为FooBean.java；scons需要调用工具生成Foo.java，FooLocal.java-，FooHome.java，FooLocalHome.java；然后scons调用javac将这5个文件编译成.class。这个例子应该和yacc，y-lex生成代码的例子是一样的。

[Charles Wang]

奇怪哈，我记得scons的作者一直生成要支持到python-1.95以后的所有版本，据说是从那时候起提供了一些关键性的功能。
难道现在不是这样了？

总之我是用gentoo的，不管python还是scons总是最新版本的了，呵呵。

On 9月9日, 上午11时32分, "Jiahua Huang" <jhuangjia...@gmail.com> wrote:

[Zoom.Quiet]

2008/9/9 Charles Wang <charles...@gmail.com>:
> 你这个问题我以前经历过的，那次我好像是要做自动从网上下载包文件吧。
>
有料!收藏!

http://wiki.woodpecker.org.cn/moin/PyScons/CharlesWang

--

http://zoomquiet.org'''

[Gang Chen]

2008/9/9 Charles Wang <charles...@gmail.com>:

> 这里牵涉到一个概念，用久了scons会注意到，它把它的运行过程明确划分成两个阶段：
> 1、运行所有SConstruct/SConscript，收集到所有的依赖性关系；

ANT没有这样的过程，它不处理依赖，写build.xml时由作者控制

> 2、分析依赖性关系，执行必须执行的操作；

ANT不分析依赖关系，按build.xml的task出现先后顺序调用

> 根据你的描述，FooBean.java 应该是含有了用于生成FooBean.class的完整信息了的，毕竟Foo.java、
> FooLocal.java都是从FooBean.java中生成的啊。那么javac 为什么不能直接从FooBean.java生成
> FooBean.class 呢？中间文件难道还可能被修改或者被其他文件所依赖吗？呵呵，我不懂java的啊。

其实这些都是Java无聊的spec定义出来的，这些Foo.java，FooLocal.java本应由程序开发人员编写，但是有人要偷懒。这几个文件的内容，FooBean.java就可以提供了，何不做个工具。javac只是单纯的从.java生成.class文件。貌似JDK5之后出现的apt可以代替javac，并且提供自定义的编译过程（例如：编译时生成文件，再编译生成的文件），但是目前较少看到自定义的apt工具库。

[Gang Chen]

2008/9/9 Charles Wang <charles...@gmail.com>:
> 总之我是用gentoo的，不管python还是scons总是最新版本的了，呵呵。

Gentoo同好 :-)

[Jiahua Huang]

On 9/9/08, Charles Wang <charles...@gmail.com> wrote:
> 总之我是用gentoo的，不管python还是scons总是最新版本的了，呵呵。
>

Gentoo 也曾经很长一段时间 mask 了 Python2.5

[Charles Wang]

> ANT没有这样的过程，它不处理依赖，写build.xml时由作者控制

我觉得依赖关系在某些情况下会是动态的。比如说有三个源文件：main.c、core-arm.c 和 core-x86.c，当目标机
为 arm 的时候，源代码是： main.c 和 core-arm.c，当目标机是 x86 的时候，源代码是 main.c、core-
x86.c，
这时候是不是要给ant准备不同的build.xml啊？如果这种选项组合太多了怎么办？在scons里面有python做后盾，
怎么复杂的变换处理都能实现了。

>
> > 2、分析依赖性关系，执行必须执行的操作；
>
> ANT不分析依赖关系，按build.xml的task出现先后顺序调用

这个我不太理解，如果ant不分析依赖关系，仅仅是按照task的顺序调用，那还不如直接用shell脚本把编译的命令罗列一番。
我想你的意思是，它就只是按顺序独立地考察每条规则。看依赖关系列表中的文件是否发生了改变，如果发生了改变就运行
对应动作，是这样吧？这等于说是把规则与规则之间的关联任务交给用户了。而且给并行编译造成了相当的困难吧？照这么说
ant应该不支持类似 make -j 3 这样的功能了？

既然谈到依赖关系分析这点，其实我们可以想想BuildSystem存在的目的。我个人感觉目的有二：一、通过智能化的依赖关系分析，
尽最大可能减少耗费时间的编译操作(也可以推广到其他长操作)；二、传播统一管理的配置信息。

其中第一点是获得广泛注意的，也是所有BuildSystem工具都做了的。呵呵，我看如果不是因为这个，这些工具也没必要存在了。
而且，不需要利用依赖性分析优化减少长操作的任务，也没必要使用make、cmake、scons 或者 ant 了。比如说scons没有对
install/uninstall操作的直接支持，我看到过许多邮件列表里有抱怨。但我想作者的意思应该是：这些没有依赖性分析的序列操作，
应该是用shell脚本来完成的。

当然我觉得第二点也相当重要，原因就是如前面所说，配置信息只出现在一处可以避免多处出现同一配置可能造成的不一致的BUG。
比如说，kernel、busybox 的 build system 就在配置信息管理方面做得比较完善。

照你个刚才对ant的描述，第二个问题压根就没涉及、第一个问题也只做了规则之内的依赖性分析，而没有做规则之间的依赖性分析。
而考虑到scons以强大的python为后盾，实现个配置信息管理是很容易的了。比如说要谈出一个kernel 的 xconfig 那种界面，
我们只要装个 pygtk 就轻松搞定了。

>
> 其实这些都是Java无聊的spec定义出来的，这些Foo.java，FooLocal.java本应由程序开发人员编写，但是有人要偷懒。这几个文件的内容-，FooBean.java就可以提供了，何不做个工具。javac只是单纯的从.java生成.class文件。貌似JDK5之后出现的apt可以代替jav-ac，并且提供自定义的编译过程（例如：编译时生成文件，再编译生成的文件），但是目前较少看到自定义的apt工具库。
>
呵呵，历史总是要给我们留下一些遗产的啊，这是没办法的哦。

[Charles Wang]

我正在做的一个小项目，从 Python Package Index 自动生成 ebuild。因为我发现 PyPI 上好多包，gentoo
portage 里面
都没有及时更新。而这些包的 ebuild 又都差不多，所以产生了自动生成 ebuild 的想法。有空去看看了：

http://code.google.com/p/pypi2pkgsys/
http://pypi.python.org/pypi/pypi2pkgsys

On 9月9日, 下午12时13分, "Gang Chen" <gon...@gmail.com> wrote:
> 2008/9/9 Charles Wang <charlesw123...@gmail.com>:
>

[Jiahua Huang]

On 9/9/08, Charles Wang <charles...@gmail.com> wrote:

> 我正在做的一个小项目，从 Python Package Index 自动生成 ebuild。因为我发现 PyPI 上好多包，gentoo
> portage 里面
> 都没有及时更新。而这些包的 ebuild 又都差不多，所以产生了自动生成 ebuild 的想法。有空去看看了：
>
> http://code.google.com/p/pypi2pkgsys/
> http://pypi.python.org/pypi/pypi2pkgsys
>

赞，

不过你怎么考虑包冲突呢？

像 Ubuntu 里边， gtkmozembed、python-gnome2、python-gnome2-extras、python-gnome2-desktop
等的包，
pypi 上的就是冲突的

[Gang Chen]

2008/9/9 Jiahua Huang <jhuang...@gmail.com>:

是时候fork了 :-)

[Jiahua Huang]

On 9/9/08, Gang Chen <gon...@gmail.com> wrote:
> 是时候fork了 :-)
>

似乎冲突的原因主要是 pypi 上的包没有及时更新，

[Gang Chen]

2008/9/9 Charles Wang <charles...@gmail.com>:

> 我正在做的一个小项目，从 Python Package Index 自动生成 ebuild。因为我发现 PyPI 上好多包，gentoo
> portage 里面
> 都没有及时更新。而这些包的 ebuild 又都差不多，所以产生了自动生成 ebuild 的想法。有空去看看了：
>
> http://code.google.com/p/pypi2pkgsys/
> http://pypi.python.org/pypi/pypi2pkgsys

不知道ebuild和eazy_install能否集成。很少用ebuild装python package，除非是系统强制的。

[Charles Wang]

现在只能做到自动生成一部分包的 ebuild。我大概检查了1000多个包，其中有400多有这样那样的问题。
有的根本无法下载，有根本连接不上，还有的在 setup 里面 Import 一些莫名其妙的东西。那叫一个乱啊，
呵呵。我这个绝对是DirtyWork。

总之一步一步来吧，先把 pypi 上4000多个包都过一遍再说。有些实在太垃圾的就干脆放弃。

On 9月9日, 下午1时45分, "Jiahua Huang" <jhuangjia...@gmail.com> wrote:

[Zoom.Quiet]

2008/9/9 Charles Wang <charles...@gmail.com>:

> 我正在做的一个小项目，从 Python Package Index 自动生成 ebuild。因为我发现 PyPI 上好多包，gentoo

> portage 里面都没有及时更新。而这些包的 ebuild 又都差不多，所以产生了自动生成 ebuild 的想法。有空去看看了：
>
嗯嗯嗯,持续收录!
http://wiki.woodpecker.org.cn/moin/PyScons/CharlesWang

强烈建议 C.Wang 直接来啄木鸟,完善:
http://wiki.woodpecker.org.cn/moin/PyScons
是也乎,是也乎!

> http://code.google.com/p/pypi2pkgsys/
> http://pypi.python.org/pypi/pypi2pkgsys
>
> On 9月9日, 下午12时13分, "Gang Chen" <gon...@gmail.com> wrote:
>> 2008/9/9 Charles Wang <charlesw123...@gmail.com>:
>>
>> > 总之我是用gentoo的，不管python还是scons总是最新版本的了，呵呵。
>>
>> Gentoo同好 :-)

--

http://zoomquiet.org'''

[Charles Wang]

邮件列表里面写的，还是乱点，是一种对话讨论的形式。等我整理一下思路，形成一篇文章，逻辑关系会更加清晰一些。

By the way，pypi2pkgsys 根 scons 没啥关系，至少目前是这样的，呵呵。

On 9月9日, 下午3时32分, Zoom.Quiet <zoom.qu...@gmail.com> wrote:
> 2008/9/9 Charles Wang <charlesw123...@gmail.com>:> 我正在做的一个小项目，从 Python Package Index 自动生成 ebuild。因为我发现 PyPI 上好多包，gentoo

> > portage 里面都没有及时更新。而这些包的 ebuild 又都差不多，所以产生了自动生成 ebuild 的想法。有空去看看了：
>

> 嗯嗯嗯,持续收录!http://wiki.woodpecker.org.cn/moin/PyScons/CharlesWang

[Qiangning Hong]

2008/9/9 Charles Wang <charles...@gmail.com>:

> 我正在做的一个小项目，从 Python Package Index 自动生成 ebuild。因为我发现 PyPI 上好多包，gentoo
> portage 里面
> 都没有及时更新。而这些包的 ebuild 又都差不多，所以产生了自动生成 ebuild 的想法。有空去看看了：
>
> http://code.google.com/p/pypi2pkgsys/
> http://pypi.python.org/pypi/pypi2pkgsys

有没有考虑过和 g-pypi 项目合并呢？
http://code.google.com/p/g-pypi/

--
Qiangning Hong
http://www.douban.com/people/hongqn/

[scaner]

用过一段时间Scons, 开始觉得挺不错的，后来有一个问题不是很好搞定，

makefile里面可以方便的触发一个脚本，比如加上build时间版本号等等动态信息,
在Scons里面做特别的麻烦，还有一点其他的变态需求，没搞定，就放弃了.

总的来说，对于普通的项目还是挺方便的，自己做定制的话，就稍微有点麻烦，
特别是不太合scons逻辑的事情.

On 9月9日, 上午10时07分, "Gang Chen" <gon...@gmail.com> wrote:
> 2008/9/9 Charles Wang <charlesw123...@gmail.com>:
>

> > 哦，我是从来没用过Java，所以没接触到你的问题。不过这种新生的软件有细节问题也不奇怪，前些天我还遇到
> > 在Windows下路径解析的问题呢，对此我主要是看主流的。你可以把你的具体问题说说，看看我是否能帮你，呵呵。
>
> > 使用scons以后，由于它的依赖性关系非常完整，我基本上不必再运行 scons -c (对应于 make clean)了。
>
> scons的自动发现源文件依赖＋手工植入源文件依赖，可以为编写构建脚本剩下不少时间。
>

> 我的情况比较特殊，举一个EJB的例子：我提供的源文件为FooBean.java；scons需要调用工具生成Foo.java，FooLocal.java ，FooHome.java，FooLocalHome.java；然后scons调用javac将这5个文件编译成.class。这个例子应该和yacc，y lex生成代码的例子是一样的。
>

> 个人感觉scons还是比较适合C/C++类型的项目使用。
>
> @Charles Wang
> 不用在上面的问题上太花时间，我现在还是回归到ANT了。
>

[大熊]

不知waf怎样，有谁试过？

xmms2使用了这个东东

--
茫茫人海，总有我的最爱
骑车带人时才最明白老婆身材的重要
日撑俯卧三百个，不辞长做天朝人

[Gang Chen]

2008/9/10 大熊 <bears...@gmail.com>:
> 不知waf怎样，有谁试过？
>
> xmms2使用了这个东东

xmms2的开发人员很赶潮流啊，两年前用scons，git，现在居然又换了。

[hongqing.lv]

以前曾经了解过。不过。因为不支持Delphi，所以就没有再看了。你说了这么多，
看来要再研究一下如何让他支持Delphi了。
Charles Wang wrote:
> 呵呵，看来这个软件在国内接触的人确实不多。我注意BuildSystem是相当早了，最早在1999年
> 的时候发狠把当时的autoconf、automake手册给翻译成中文了。在相当长的一段时间之内，个人
> 感觉autoconf/automake/make的组合是可以满足基本需求的。所以当时还进一步翻译了GNU 软件
> 发行惯例。这些译文大家都可以在 http://www.linuxforum.net/books/index.php 看到。
>
> 大约在2001年吧，我开始在Linux下做嵌入式开发。此前虽然发现了一些autoconf/automake/make
> 的问题，但还没到痛苦的地步。因为嵌入式Linux系统，要多出交叉编译和系统生成两大块任务，
> 用autoconf/automake/make就开始感受到限制了。当然那时候还不知道什么其他的创建工具的存在，
> 所以就仿照 kernel build system 的方法，用make来做。其间也确实遭受了不少痛苦经历，呵呵。
>
> 后来在2003年终于忍无可忍，开始寻找新工具。找来找去，由于偶然或非偶然的机会，发现了scons。
> 用过之后就再也没改了。那时候scons的版本还比较低，不过已经相当好用了。这里列举一下区别吧：
>
> * 对交叉编译的支持：
> autoconf/automake/make 把所有的变量名都放在一个命名空间之中，这使得我们只能用不同的变量
> 名来区分用于不同体系的编译宏。例如，在kernel build system里面，CC这个变量是用于编译目标
> 体系结构的代码的，而HOSTCC则是用于编译当前体系结构的代码的。所有其它变量都必须通过加前缀
> 的方式加以区分；
> scons 提供 Environment 对象，每个对象都是一个编译变量容器。所以针对不同的目标体系结构，
> 在scons中可以存在大量的 Environment 对象。例如像 kernel build system 那样，可以分别为目标
> 体系结构和当前体系结构定义两个明确区分的 Environment 对象。而不会造成任何混淆；
> * 如何确定一个文件是否改变：
> make 是使用文件的timestampe来检查文件是否已经被改变了。可是这就要求当前系统具有正确的
> 系统时钟。这一问题在使用CVS时会更加突出一些。因为CVS会纪录提交时间，加入CVS服务器的系统
> 时钟超前或者落后，那么肯定会造成混乱。还有一个问题就是如果通过CVS取回以前的版本，那么它
> 会把这个文件的时间设置成该文件提交的时间。如果再以时间戳为准判断文件是否改变，就会出现
> 把改变了的文件误认为没有改变的文件的情况了。
> scons 以文件内容的校验和为标志来确认文件是否被改变。以校验和为标志可以脱离对系统时间的
> 依赖，当然付出的代价是速度比时间戳慢一点。不过通过获得精确的依赖性关系所节省的时间，要比
> 依赖关系不全而被迫使用 make clean 要短许多吧。同时scons也支持使用时间戳作为判断依据。
> * 是否参考命令行的变化：
> make 在检查依赖性的时候，并不检查命令行的变化。可是命令行的变化却对目标文件的生成有着
> 很大的影响。例如，在命令行里面，加-g或不加-g、加-DNDEBUG或不加-DNDEBUG。
> scons 把命令行的变化考虑在内，如果命令行发生变化了，那么目标也必须重新编译。
> * 是否拥有全局依赖性信息：
> autoconf/automake/make 组合，以递归的方式使用 make。但是在这样的情况下，会出现问题：
> 假定源代码目录结构为根目录下有： lib、src、tools 几个目录，其中均还有源代码。那么如果在
> src 目录中执行 make，lib 目录中的文件即时发生了变化，也不会重新编译lib中的源代码。当然
> 这是由于递归方式使用make导致make没有获得完整的依赖关系造成的。具体参见：
> http://aegis.sourceforge.net/auug97.pdf
> scons 则是每次都完整地运行整个buildsystem代码，以获得完整的依赖关系。它不会出现上述缺陷。
> * 编程语言：
> autoconf/automake/make 组合，混杂了 m4、make、shell 等众多不同的脚本语言，没有一样是常用的。
> scons，纯python。由于python是全功能流行的强攻能语言，这使得组建编译系统的能力和便捷性大大增强。
> * 跨平台：
> autoconf/automake/make 在 Windows 下，必须在mingw之类的模拟环境中运行。这是因为autoconf生成的
> configure脚本使用了许多shell命令，这些都要由环境来提供。而且不同系统中的命令集合有可能不同，同一
> 命令的具体功能也可能不同。同时，make存在众多不同版本。为了弥补这些似是而非的区别，导致了
> autoconf/automake的高度复杂性。
> scons，支持跨平台，除了python 之外没有其它依赖。在Windows下即可以在mingw中运行，又可以在普通
> Windows命令行中运行。
> * 复杂度：
> autoconf/automake/make 组合，必须编写 configure.ac、Makefile.am。而最终使用的
> configure 脚本和
> Makefile 可能长达数万行，我本人就曾被这些几万行的东西搞得天昏地暗。打开一次都折寿。
> scons，脚本相当简单。在scons内部就可以自动完成各种自动依赖性的扫描。
> * 对代码生成、信息传播的支持：
> 我们知道，一项信息如果只存在于一个地方是最好的。如果存在于两个地方就可能因为不一致而造成BUG。
> 例如说，屏幕的尺寸。但是需要信息的地方可能不止一个，这时候就需要我们把仅存在于一处的信息传播
> 到所有需要它的地方。这种传播可能发生在运行时，也可能发生在编译时。发生在编译时的传播适用于在
> 软件的特定版本中不变的常量，优点是不必在运行时付出任何代价。一般而言比较简单的这类传播是
> 通过宏定义实现的，但更为复杂的就会涉及到源代码的生成。
> autoconf/automake/make 只能使用shell脚本生成，不能实现过于复杂的处理
> scons 可以用python 函数实现任意复杂度的处理。例如我曾经在我的scons脚本里面，调用 subversion-python
> 的模块，自动把svn版本号潜入到源代码中。
>
> 上面列举的区别，有些是质的区别，有些是量的区别。但是无论如何，以较低的代价获得较好的效果，使得
> 我们能够把更多的注意力放到完成BuildSystem的功能上去。所以我认为即使仅仅是量变、简化也有意义。
>
> 呵呵，不过我发现长久以来似乎国内无人注意到这一软件。我想python爱好者当中总会有人感兴趣吧？
> 在2003年我曾经使用scons开发过一个项目。连接是：http://trac.magiclinux.org/magicinstaller/
> wiki/MagicInstaller
> 不过那时候对scons的了解还很肤浅，没能做到一条命令生成整个嵌入式目标文件系统。现在已经是piece of cake了。
> >
>

[Kula]

何不用cmake..很好用

Eddie Izzard  - "Never put a sock in a toaster."

2008/9/10 hongqing.lv <hongqing.lv@gmail.com>

[Jiahua Huang]

On 9/10/08, Kula <kula...@gmail.com> wrote:
> 何不用cmake..很好用
>

python 项目就还是用
distutils 或 setuptools 吧

[Linker]

2008/9/10 Kula <kula...@gmail.com>

何不用cmake..很好用

我也推荐cmake.

非常好用。

有KDE4做实践。 

--
Linker M Lin
linker...@gmail.com

[Charles Wang]

昨天发现 Google chromium 用的是 scons，看来越来越多的人在脱离 autoconf/automake/make 组合了。

On 9月10日, 下午7时00分, Linker <linker.m....@gmail.com> wrote:
> 2008/9/10 Kula <kulas...@gmail.com>

>
> > 何不用cmake..很好用
>
> 我也推荐cmake.
> 非常好用。
> 有KDE4做实践。
>
>
>
>
>
>
>
> > Eddie Izzard - "Never put a sock in a toaster."
>

> > 2008/9/10 hongqing.lv <hongqing...@gmail.com>

> linker.m....@gmail.com- 隐藏被引用文字 -
>
> - 显示引用的文字 -