[En-Nut-Discussion] Feature Request: Create Application Directory" for (q)nutconf

Ulrich Prinz ulrich.prinz at googlemail.com
Thu Feb 16 16:00:35 CET 2012


Hi Thiago,

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


Am 15. Februar 2012 20:38 schrieb Thiago A. Corrêa <thiago.correa at gmail.com>:
> Hi,
>
>
> 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
>
> On Sun, Feb 12, 2012 at 9:30 AM, Ulrich Prinz
> <ulrich.prinz at googlemail.com> wrote:
>> Hi!
>>
>> 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
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion



More information about the En-Nut-Discussion mailing list