Re: kext programming with VIM?
Re: kext programming with VIM?
- Subject: Re: kext programming with VIM?
- From: John Dalgliesh <email@hidden>
- Date: Sat, 29 Jul 2006 17:36:01 +1000 (EST)
On Sat, 29 Jul 2006, NAHieu wrote:
On 7/29/06, John Dalgliesh <email@hidden> wrote:
... there is no reason you can't use vim to edit your sources and Xcode to
build them. Just because Xcode has an editor built in doesn't mean you
have to use it. You can use any editor to modify the files.
Of course that is possible, but then things become less fun, even
ugly. So whenever I need to add/remove a file from the project, or do
smt to the project, I need to turn on Xcode, just for that?
And this is a big deal? Seriously I think you need to get things into
perspective. Adding files is a relatively rare operation.
Whereas
with vim, I just need to open the Makefile, and modify it. Very simple
and quick shot.
But how long did you spend writing the Makefile to build the project in
the correct way?
For those are familar with programming from console/terminal, GUI is
not effiecient at all. Anybody is used to vim must agree with me :-)
I have been using vim and Makefiles as the main build tools in my work and
study for more than ten years. On the Mac I have no problem whatsoever
using Xcode for managing projects. Quite often I still use vim for editing
the source files. I certainly don't buy the argument that GUIs are
inherrently less efficient... 90% of it is what you're used to. Just like
in the vi vs emacs debate.
(Also something like:
osascript -e 'tell application "Xcode" to add file "file" to project "proj"'
would probably work too if you dislike the mouse that much.)
So there is absolutely no way to skip using Xcode??? I cannot believe that!!
Like I said in my first post, I'm sure you can write a Makefile to do what
Xcode does to build a kext. But it is not trivial, e.g. you have to
generate an info structure and link it in under a certain symbol. You're
welcome to examine the Xcode build output to see what you need to do to
avoid using it.
Thanks.
H
Oh and this isn't really the appropriate mailing list for such a
discussion. We should let the kernel people get on with their hardcode
kernel programming topics here.
{P^/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden