如何强行执行make

雨丝风片

原帖由 assiss 于 2006-9-6 15:52 发表

我在NetBSD上试用gmake，似乎也的确不能用!代替:。

我也刚在FreeBSD上用gmake实际鉴定了一下“！”的盗版行为：

1. Makefile:2: *** missing separator.  Stop.

复制代码

雨丝风片

对于gmake，只需要把相应的目标声明为 .PHONY 即可，这样不管目标和依赖之间谁先谁后，gmake都会重新生成目标。

从gmake的手册里拷了一段例子过来，仅用于说明如何声明一个目标的属性为.PHONY ：

1.      all : prog1 prog2 prog3
   
2.      .PHONY : all
   
3.      
   
4.      prog1 : prog1.o utils.o
   
5.              cc -o prog1 prog1.o utils.o
   
6.      
   
7.      prog2 : prog2.o
   
8.              cc -o prog2 prog2.o
   
9.      
   
10.      prog3 : prog3.o sort.o utils.o
    
11.              cc -o prog3 prog3.o sort.o utils.o

复制代码

另，此法为gmake 和 pmake 的通用之法。

[ 本帖最后由 雨丝风片 于 2006-9-6 16:09 编辑 ]

gvim

曰,......被骗了，看来还是要在www.gnu.org找正版才行。
pmake和gmake还有什么交集？FreeBSD官网提供的pmake教程30来页，而gmake的手册N页，没有那么多时间去了解gmake。只想知道它们之间的交集，便于抑制。
cmake怎样？我看了介绍，还不错的说，还没来得及去仔细了解。

assiss

原帖由 gvim 于 2006-9-6 16:17 发表
曰,......被骗了，看来还是要在www.gnu.org找正版才行。
pmake和gmake还有什么交集？FreeBSD官网提供的pmake教程30来页，而gmake的手册N页，没有那么多时间去了解gmake。只想知道它们之间的交集，便于 ...

前天刚被推荐去看cmake。看其介绍，似乎很不错。
推荐我看的人说KDE要全面换用cmake，尚未证实他的说法。

我是肯定没时间看了，无论IDLE还是THREAD，
GVIM兄和雨片兄有时间研究一下吧。

雨丝风片

原帖由 gvim 于 2006-9-6 16:17 发表
曰,......被骗了，看来还是要在www.gnu.org找正版才行。
pmake和gmake还有什么交集？FreeBSD官网提供的pmake教程30来页，而gmake的手册N页，没有那么多时间去了解gmake。只想知道它们之间的交集，便于 ...

很早就想好好总结一下pmake和gmake之间的恩恩怨怨了，这个问题对BSD和GNU之间的软件移植很重要，无奈一直没有找到时间去做这个事情。

assiss

原帖由 雨丝风片 于 2006-9-6 16:39 发表


很早就想好好总结一下pmake和gmake之间的恩恩怨怨了，这个问题对BSD和GNU之间的软件移植很重要，无奈一直没有找到时间去做这个事情。

时间啊时间，莫向NETBSD学习，只在用户级实现THREAD，要向FREEBSD学习，在内核级实现。

老人家说过，时间就如同那啥里的水，只要你“愿意”（内核级的）去挤，总是有的。

雨丝风片

原帖由 assiss 于 2006-9-6 16:38 发表

前天刚被推荐去看cmake。看其介绍，似乎很不错。
推荐我看的人说KDE要全面换用cmake，尚未证实他的说法。

我是肯定没时间看了，无论IDLE还是THREAD，
GVIM兄和雨片兄有时间研究一下吧。

我觉得关键不是这个make工具本身怎么样，而是为其写的makefile的移植性问题，现在光有个pmake和gmake就够头疼的了，再来个cmake，互相之间的makefile都不认，还是没有解决根本问题。

gvim

原帖由 assiss 于 2006-9-6 16:41 发表

时间啊时间，莫向NETBSD学习，只在用户级实现THREAD，要向FREEBSD学习，在内核级实现。

老人家说过，时间就如同那啥里的水，只要你“愿意”（内核级的）去挤，总是有的。

kern/kern_kthread.c 不是内核线程吗？看说明应该是吧:em11:

/*
* Fork a kernel thread.  Any process can request this to be done.
* The VM space and limits, etc. will be shared with proc0.
*/
int
kthread_create1(void (*func)(void *), void *arg,
    struct proc **newpp, const char *fmt, ...)
...

这几个守护线程也是这样生成的。

(init_main.c)
if (kthread_create1(uvm_pageout, NULL, NULL, "pagedaemon")
        panic("fork pagedaemon";

/* Create the filesystem syncer kernel thread. */
if (kthread_create1(sched_sync, NULL, NULL, "ioflush")
        panic("fork syncer";

/* Create the aiodone daemon kernel thread. */
if (kthread_create1(uvm_aiodone_daemon, NULL, &uvm.aiodoned_proc,
    "aiodoned")
        panic("fork aiodoned";

我对scheduler activations老建立不起来细节概念，还望as兄指教

gvim

原帖由 雨丝风片 于 2006-9-6 16:42 发表


我觉得关键不是这个make工具本身怎么样，而是为其写的makefile的移植性问题，现在光有个pmake和gmake就够头疼的了，再来个cmake，互相之间的makefile都不认，还是没有解决根本问题。

我大概看了看cmake的windows的界面(没有看说明，呵呵，懒一下)，根据界面上的东西，我推测应该是在平台上检测拥有的make版本，或者用户自己指定，然后根据一份文件列表生成对应的makefile。如nmake就生成nmake的makefile，pmake就生成pmake的makefile。当然，肯定还有其他的控制属性。
据说不是很难，所以就懒。

[ 本帖最后由 gvim 于 2006-9-6 17:04 编辑 ]

assiss

原帖由 gvim 于 2006-9-6 16:58 发表


kern/kern_kthread.c 不是内核线程吗？看说明应该是吧:em11:

这几个守护线程也是这样生成的。


我对scheduler activations老建立不起来细节概念，还望as兄指教

大哥对比一下FreeBSD
src/kern/kern_thread.c
http://fxr.watson.org/fxr/source//kern/kern_thread.c
就知道NetBSD在内核级线程上的支持有多弱了。
我不知道NetBSD在这方面跟FB差多远。

也许我们讨论的“内核级线程”和“内核线程”根本不是同一个东西----相比而言，我更多的注意力在用户层面上。

你在内核研究上远比我进步，还让我“指教”你，一边玩去。