README update

git-svn-id: svn://svn.code.sf.net/p/nuttx/code/trunk@3087 42af7a65-404d-4744-a932-0658087f49c3
This commit is contained in:
patacongo 2010-11-06 23:41:08 +00:00
parent c7ae3ecc73
commit a4e888b714
2 changed files with 46 additions and 19 deletions

View File

@ -60,7 +60,7 @@ Installation Directories with Spaces in the Path
the make system tries to build.
[Actually, that problem is probably not to difficult to fix. Some
Makefiles probably just need some pathes within double quotes]
Makefiles probably just need some paths within double quotes]
I work around spaces in the home directory name, by creating a
new directory that does not contain any spaces, such as /home/nuttx.
@ -157,19 +157,44 @@ NuttX Buildroot Toolchain
BUILDING NUTTX
^^^^^^^^^^^^^^
NuttX builds in-place in the source tree. You do not need to create
any special build directories. Assuming that your Make.defs is setup
properly for your tool chain and that setenv.sh contains the path to where
your cross-development tools are installed, the following steps are all that
are equired to build NuttX:
Building
cd ${TOPDIR}
. ./setenv.sh
make
NuttX builds in-place in the source tree. You do not need to create
any special build directories. Assuming that your Make.defs is setup
properly for your tool chain and that setenv.sh contains the path to where
your cross-development tools are installed, the following steps are all that
are equired to build NuttX:
At least one configuration (eagle100) requires additional command line
arguments on the make command. Read ${TOPDIR}/configs/<board-name>/README.txt
to see if that applies to your target.
cd ${TOPDIR}
. ./setenv.sh
make
At least one configuration (eagle100) requires additional command line
arguments on the make command. Read ${TOPDIR}/configs/<board-name>/README.txt
to see if that applies to your target.
Re-building
Re-building is normally simple -- just type make again.
But there are some things that can "get you" when you use the Cygwin
development environment with Windows native tools. The native Windows
tools do not understand Cygwin's symbolic links, so the NuttX make system
does something weird: It copies the configuration directories instead of
linking to them (it could, perhaps, use the NTFS 'mklink' command, but it
doesn't).
A consequence of this is that you can easily get confused when you edit
a file in one of the linked (i.e., copied) directories, re-build NuttX,
and then not see your changes when you run the program. That is because
build is still using the version of the file in the copied directory, not
your modified file! To work around this annoying behavior, do the
following when you re-build:
make clean_context all
This 'make' coimmand will remove of the copied directories, re-copy them,
then make NuttX.
CYGWIN BUILD PROBLEMS
^^^^^^^^^^^^^^^^^^^^^
@ -187,7 +212,7 @@ When you install some toolchains (such as Yargarto or CodeSourcery tools),
they may modify your PATH variable to include a path to their binaries.
At that location, they make have GNUWin32 versions of the tools. So you
might actually be using a version of make that does not understand Cygwin
pathes.
paths.
The solution is either:

View File

@ -297,13 +297,15 @@ Make Tip
^^^^^^^^
Because this build uses a native Windows toolchain and the native Windows
does not understand Cygwin/POSIX paths, the NuttX make sysem does something
weird: It copies the configuration directories instead of simply linking
to them (it could, perhaps, use the NTFS mklink command, but it doesn't).
tools do not understand Cygwin's symbolic links, the NuttX make system does
something weird: It copies the configuration directories instead of linking
to them (it could, perhaps, use the NTFS 'mklink' command, but it doesn't).
A consequence of this is that you can easily get confused and get editting
a file in one of the linked directories, re-build, and not see your changes.
To work around this annoying behavior, I also do the following when I make:
A consequence of this is that you can easily get confused when you edit
a file in one of the "linked" directories, re-build NuttX, and then not see your
changes when you run the program. That is because build is still using the
version of the file in the copied directory, not your modified file! To work
around this annoying behavior, do the following when you re-build:
make clean_context all <-- Remove and re-copy all of the directories, then make all
doisp.sh <-- Load the code onto the board.