[En-Nut-Discussion] Feature Request: Create Application Directory" for (q)nutconf
Ulrich Prinz
If you develop with nutos and use (q)nutconf you like to press the
button 'Create Sample Directory' and have your build system set up in
the given directory.
But if you develop lots of your own projects you might not like to
have all the examples installed.
This gets even more disturbing if you implement new architectures and
have to add and change nut/app/Make*.* files that are used to create
the needed NutConf.mk and others in the top application directory.
With every 'Create Sample Directory' call the examples are reinstalled.
So I guess it could help to add and sort the Build->xxx menu like this:
1) Create/Update Application Directory
2) Copy Examples to Application Directory
Option 1 only creates or updates the given application directory
Option 2 calls optionn 1 and then additionally copies over all non
existing files from the nut/app directory.
3) Copy Hardware Testing Code
There could be an Option 3 after we moved out the hardware driver test
examples like eeprom, PCF expander and others that are very hardware
dependent to a different directory.
Option 3 then calls Option 1 and additionally copies all non existing
files from that driver test directory to the application dir.
How about that?
Ulrich
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion
Ole Reinhardt
> But if you develop lots of your own projects you might not like to
> have all the examples installed.
Yes, I well know this problem. I personally prefer to have a
pre-compiled Nut/OS and to use just a few simple makefiles with my
application, not all this directory hirarchy.
Especialy when deploying Nut/OS as development environment for a board
your customers won't ever compile Nut/OS by their own but just use the
ready build libraries.
So what I would suggest is to add an "Install Nut/OS" which would build
the libraries, install it into a folder and add the necessary makefiles
(just the ones for your compiler setting)
As an example see
http://www.embedded-it.de/bsp-download/webserver_relais_demo.tar.gz
(folder Nut/OS)
I also modified the application standard makefiles to refer to the
pre-installed ones.
Another idea:
This install button could also copy the header files so that one would
not have to install the whole source tree too.
Bye,
Ole
--
Thermotemp GmbH, Embedded-IT
Embedded Hard-/ Software and Open Source Development,
Integration and Consulting
Geschäftsstelle Siegen - Steinstraße 67 - D-57072 Siegen -
tel +49 (0)271 5513597, +49 (0)271-73681 - fax +49 (0)271 736 97
Hauptsitz - Hademarscher Weg 7 - 13503 Berlin
Tel +49 (0)30 4315205 - Fax +49 (0)30 43665002
Geschäftsführer: Jörg Friedrichs, Ole Reinhardt
Handelsregister Berlin Charlottenburg HRB 45978 UstID DE 156329280
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion
Ulrich Prinz
At first the separation of directory and makefile generation from
creation of all examples would be very helpfull.
To add an option that enables to export all libraries and headers and
creates a set of working application makefiles is very fine.
We often need to keep nut/os libraries synced with the application
source code to be able to reproduce avery single software release.
So if we could export the libraries and headers in parallel with the
applications it would be very handy for checking them in to SVN or
GIT.
Ulrich
Am 08.02.2012 15:52, schrieb Ole Reinhardt:
> Hi Ulrich,
>
>> But if you develop lots of your own projects you might not like to
>> have all the examples installed.
>
> Yes, I well know this problem. I personally prefer to have a
> pre-compiled Nut/OS and to use just a few simple makefiles with my
> application, not all this directory hirarchy.
>
> Especialy when deploying Nut/OS as development environment for a board
> your customers won't ever compile Nut/OS by their own but just use the
> ready build libraries.
>
> So what I would suggest is to add an "Install Nut/OS" which would build
> the libraries, install it into a folder and add the necessary makefiles
> (just the ones for your compiler setting)
>
> As an example see
>
> http://www.embedded-it.de/bsp-download/webserver_relais_demo.tar.gz
>
> (folder Nut/OS)
>
> I also modified the application standard makefiles to refer to the
> pre-installed ones.
>
> Another idea:
>
> This install button could also copy the header files so that one would
> not have to install the whole source tree too.
>
> Bye,
>
> Ole
>
>
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion
Thiago A. Corrêa
I have been wondering for a while how we could have a "New Project
with Nut/OS" kind of wizard, like visual studio, into qnutconf and how
it would build you the basic makefiles. It's interesting to know how
ppl actually use Nut/OS in their environment.
In particular, I keep my nuts/os in c:\programming\ethernut and my
projects as c:\programming\comm5\firmware\<project>
Inside <project> I create a makefile that references the sample
makefiles like this:
include /programming/ethernut/nutapp/Makedefs
SRCS = mysource.c
LIBS = $(LIBDIR)/nutinit.o -lnutos -lnutarch -lnutdev -lnutcrt -lnutc -lnutgorp
OBJS = $(SRCS:.c=.o)
TARG = $(PROJ).hex
all: $(OBJS) $(TARG) $(ITARG) $(DTARG)
dep:
$(CC) -I$(top_srcdir)/include -M main.c
include /programming/ethernut/nutapp/Makerules
It's simple and shouldn't be hard to generate, yet I don't think it's
simple enough for the beginner. I'm interested in opinions.
Kind Regards,
Thiago A. Correa
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion
Ulrich Prinz
Im an not sure if it is wise to only keep one nut/os for several
different projects...
In commercial programming you need to be able to restore every release
of your software and sometimes you must restore an old state that has
generates an identical md5sum of the binry output.
So if you in the meantime have improved nut/os with some things, you
cannot restore the project to an identical checksum as the libraries
have changed.
What we do is to keep the following structure under version control:
project-x/nut
project-x/nutapp-arch-gcc
project-x/nutapp-arch-gcc/bootloader
project-x/nutapp-arch-gcc/device-a
project-x/nutapp-arch-gcc/device-b
project-x/nutapp-arch-gcc/device-c
So if a new person joins development,
- he checks out project-x
- starts qnutconf with the project-x.conf file
- builds nut/os
- build application
If a new project is started you can either switch / branch to it from
an existing constellation or you could export your current
projext-x/nut to a new porject-y.
- run qnutconf with a most matching existing conf, modify it and do an
initial checkin.
- build nut/os, create sample directory
- add your new device-f or copy/rename a matching demo code (mostly
uart demo :) )
- delete all unneeded demo directories.
- check in the device
With that procedure you can keep the nut/os and application / device
sources und strict version control.
It is even possible to switch achitecture in the evaluation phase of a
project and keeping both architectures side by side to see what is
most efficient.
So for me it is really helpfull to be able to create and (important)
update that nutapp-arch-xyz directory including all Makefiles but
excluding all demos.
What we did in the past was to take nut/os from sourceforge and our
applications from our own version control system. But it showed up
that this was not working as there is no link between the application
software version and the nut/os software version. You either need to
check in nut/os in an unclean state to have a fixed revision number or
you have to track all differencs to the last checkout.
Any other way will lead to the situation where the last generated
binary file for a device cannot be reproduced anymore.
Best regards
Ulrich
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion