PDA

View Full Version : Build nano in XCode




CraigularB
Jan 7, 2012, 04:50 PM
Hi all,

I've been programming for a few years now but I'd like to try and expand my experience a little so I thought I'd take a look at the source for some open source projects. I use Nano (the text editor) a lot, so I started there. I have the source downloaded (and I also built it via ./configure && make, builds and runs just fine).

What I'd like to do is edit and build it in XCode. I find that I enjoy development in an IDE because I'm not switching between open windows so much, along with the graphical interface to GDB and code completion. So I created a project and added Nano's source but it fails to compile.

I read somewhere that you have to take every step of the makefile and create a target for that step; is there an easy way to do this, or some tutorial somewhere, or any good advice that people could point me to?

Thanks for the help! For now I'll use TextEdit to view the source just so I can start figuring things out :)

-Craig



subsonix
Jan 7, 2012, 05:24 PM
I'm a bit confused, you like Nano, but you use Xcode because you prefer an IDE, except now you use TextEdit. Nano is already built and included in OS X.

CraigularB
Jan 7, 2012, 05:32 PM
I'm a bit confused, you like Nano, but you use Xcode because you prefer an IDE, except now you use TextEdit. Nano is already built and included in OS X.

I use Nano if I have a small change to make quickly. I use TextEdit for viewing larger source files if they're not in an XCode project or I don't need syntax highlighting. I (try to) use XCode to write the majority of my code and compile/run/debug the executable. I try and familiarize myself with as much as I can, hence the multiple editors (I also use vim and have been using emacs a little; no strong preferences, I just like trying new things).

I realize Nano is already included in OSX, I just wanted to see the source and play around with it and see how it works. I find doing my coding in an IDE (XCode) makes it easier for me to keep track of what files have what and where they are, I think the highlighting and completion is good, and it also keeps the window-switching down (since I'm not switching between an editor and the terminal all the time). I also like the built-in debugging interface. So, basically, I prefer to use XCode. I can code in Nano/vim/whatever and compile it on the command line fine, I just like an IDE.

robvas
Jan 7, 2012, 05:46 PM
I'm a bit confused, you like Nano, but you use Xcode because you prefer an IDE, except now you use TextEdit. Nano is already built and included in OS X.

He wants to use XCode to build nano.

chown33
Jan 7, 2012, 06:03 PM
... So I created a project and added Nano's source but it fails to compile.

Then you should probably post the error messages. Because "it fails to compile" isn't descriptive.


I read somewhere that you have to take every step of the makefile and create a target for that step; ...


A separate Xcode target for each step seems excessive. As in, it seems unlikely to me, speaking from the experience of having converted several makefiles to Xcode projects, and vice versa.

However, it's going to depend a lot on the actual makefile, and on the Xcode project template you start with. I haven't read nano's makefile so I can't comment on it. And you haven't described anything about your Xcode project, so I can't comment on that, either.

I'm not sure what to suggest, except maybe starting with a simpler project.

For example, create a make-based project with 2 C source files. Ensure it works. Then convert that to an Xcode project. Or go the other way: take an Xcode command-line tool project and create a makefile for it.

If you know make, then it shouldn't be rocket science to figure out a makefile for a simple 2-file project. Conversely, if you have a makefile for building 2 simple C files into a command-line tool, it shouldn't be rocket science to figure out the corresponding Xcode project. To be specific, if you know how a command-line tool is put together in an Xcode project, you'll know there's not a target for each step.

If you don't know make, then you'll need to study it. There are any number of books and tutorials. You could do worse than the O'Reilly book.

subsonix
Jan 7, 2012, 06:06 PM
He wants to use XCode to build nano.

Understood, my question was more along the lines of why. But never mind.

CraigularB: Post the errors you are getting.

CraigularB
Jan 7, 2012, 06:15 PM
So as of now, I get "glib.h file not found" when I compile in XCode. However, like I said, I can compile at the command line. I've used makefiles for multi-source projects before but nothing as in-depth as the one I see for Nano. I'll take a better look at it when I have some more time and see what's up.

jiminaus
Jan 7, 2012, 06:27 PM
When you built from the command-line, the gcc and/or ld commands would have included -I (capital eye) and -L options. These add path to the search paths for include files and library files respectively. You'll need to effectively replicate these options in your build settings so XCode can find glib.h.

balamw
Jan 7, 2012, 06:33 PM
Further to the last post, you can get more info by looking at the command lines make used vs. what Xcode used. If you post them we may be able to point you in the right direction.

B

CraigularB
Jan 10, 2012, 01:11 PM
Further to the last post, you can get more info by looking at the command lines make used vs. what Xcode used. If you post them we may be able to point you in the right direction.

B

I think I've got things sort-of figured out, but unfortunately I've hit a roadblock (will explain).

Instead of looking at the makefile I just decided to run make and look at the output in the terminal. I get this command run for every source file:
gcc -DHAVE_CONFIG_H -I. -I.. -DLOCALEDIR=\"/usr/local/share/locale\" -DSYSCONFDIR=\"/usr/local/etc\" -g -MT winio.o -MD -MP -MF winio.Tpo -c -o winio.o winio.c

Of course the filename is changed for every file, but the flags are all exactly the same for each source file. I've put these in the "flags" portion for each source file. The final command is:
gcc -g -O2 -o nano browser.o chars.o color.o cut.o files.o global.o help.o move.o nano.o prompt.o rcfile.o search.o text.o utils.o winio.o -lncurses

I've added these to my XCode project (screenshots attached) along with something I think I need because of glib (it complains about files missing without these lines). Basically I had to run pkg-config to output the correct compiler flags for building with glib like this: pkg-config --libs --cflags glib-2.0

I've also added /opt/local/lib/glib-2.0/include and /opt/local/include to my header search paths.

So, since when I run make it uses GCC I switched the compiler to the LLVM GCC compiler in XCode (it should be the same one that make is calling). Unfortunately I get 13 errors and 6 warnings in the build. I think it's because XCode is using the LLVM GCC compiler and make is calling just GCC, but I'm not sure if I can fix it. At this point I'm a little stuck. If anyone has any input I'd be grateful :)

Thanks!
-Craig

r0k
Jan 10, 2012, 02:32 PM
Could you start a new "command line" executable project in Xcode and drag in the nano sources one by one? Perhaps it will build correctly in Xcode then.

jiminaus
Jan 10, 2012, 02:51 PM
You have -DHAVE_CONFIG_H. If you do that, you'll need run ./configure from the command-line to get Config.h.

jiminaus
Jan 11, 2012, 03:07 AM
Okay, I bit the bullet and compiled nano in XCode. Here's how I did it.


Download the nano source code.
Extract the source code somewhere.
Run configure to generate config.h
Create a new C command-line project in XCode.
In Finder, navigate to the extract nano source code.
Drag config.h into the XCode project.
In Finder, navigate to the src folder.
Drag the *.h and *.c files into the XCode project.
Go into the target build settings
Under Search Path, change Always Search User User Path to Yes.
Under Apple LLVM compiler 3.0 - Preprocessing, remove DEBUG=1 and replace it with HAVE_CONFIG_H LOCALEDIR=\"/usr/local/share/locale\" SYSCONFDIR=\"/usr/local/nano/etc\"
Go into the target build phases
Add libncurses.dylib under Link Binary With Libraries


You'll get LOTS of warnings, but this is because the code uses some old-school C (like not prototyping functions before their use). It should still successfully build and run.

But speaking of running, it won't run within XCode, because the program uses curses. You need to run it directly from the command prompt. But where is the executable? You won't find it anywhere within your XCode project folder.

XCode stores all its stuff in a DerivedData folder. To find the executable:

Go into XCode's Preferences
Go into the Locations section
Go into the Locations tab
Under Derived Data, you'll see the path to the derived data folder. Click the circle with the arrow to open this folder in Finder.
You'll see a folder whose name starts with name of your project, followed by some "random" stuff. Go into this folder.
Go into Build/Products/Debug

In that folder, you'll find the nano executable.


And now that you've done all that, you'll rightly say "Why the hell did I do all that for?".

r0k
Jan 11, 2012, 06:58 AM
Okay, I bit the bullet and compiled nano in XCode. Here's how I did it.

...
And now that you've done all that, you'll rightly say "Why the hell did I do all that for?".

Because it's there! :D

Good job, btw!

chown33
Jan 11, 2012, 09:58 AM
XCode stores all its stuff in a DerivedData folder. To find the executable:

Go into XCode's Preferences
Go into the Locations section
Go into the Locations tab
Under Derived Data, you'll see the path to the derived data folder. Click the circle with the arrow to open this folder in Finder.
You'll see a folder whose name starts with name of your project, followed by some "random" stuff. Go into this folder.
Go into Build/Products/Debug

In that folder, you'll find the nano executable.

There should be a setting that lets you specify a location for the derived data.

So in cases where you care about the location, like this one, you can set it. Otherwise you don't care, and the "random" location suffices.