[En-Nut-Discussion] qnutconf path mysteries

[Thiago A. Corrêa]

Hi,

On Tue, Dec 8, 2009 at 9:52 AM, Harald Kipp <harald.kipp at egnite.de> wrote:
>
> start searching at the installation directory and stop searching as soon
> as they find
>
> C:\ethernut-4.9\crossworks\nut\...
>
> which is just a temporary directory containing a few patches, but no
> conf directory.
>

It must contain an os/version.c in that path, as that's what it looks
for, like nutconf. We could simplify and look for conf/repository.nut
but then if you had a temporary directory containing that file, the
same thing would happen.

>
>
> I'm not yet sure how to fix this in a right way, because ...

Does it needs fixing? I'm not sure if this situation needs fixing?
Although in practice a single configurator *could* work with any
version of Nut/OS, this might not be always true, and I belive
shouldn't be officially supported. I think (q)nutconf should be run
directly below the nut folder containing sources. If you have multiple
versions, than each version folder should have it's corresponding
(q)nutconf. This way, if at some later date we decide to make some
change, or we need a new lua binding (lua script needs to figure out
the compiler for example, that could be nice), then repository.nut
becomes tied to a version of (q)nutconf

>
> If we then start qnutconf from C:\ethernut-x.y.z on Windows or
> ~/ethernut on Linux/OS X, it will fail.
>

Running from c:\Ethernut-x.y.z should work fine. It wouldn't work if
run from c:\ethernut with c:\ethernut\4.0\nut, c:\ethernut\4.1\nut and
so on. In this case, I don't think there is a way for (q)nutconf to
figure which one you want, and having the user to choose each time is
problematic. Having him remember to change the repository folder at
the settings dialog is error prone.

Here I have this structure:
\programming\ethernut\nut
\programming\ethernut-uc3\nut
\programming\ethernut-working
\programming\ethernut-uc3-export

Each have their own copy of nutconf, and I run/develop qnutconf from
inside \programming\ethernut\nut\tools\qnutconf. It's run from there
in here, but I tested running it from \programming\ethernut and it
works properly this way.


About the "allow multiple configurations" I agree. It doesn't work
propery at all (nutconf). The problem with saving it in the .conf file
is that the command line would have to be extended in the same way. I
thought of creating a "project" with xml containing a reference for
the .conf file and the compiler settings. I didn't consider fixing the
nutrepository.nut path problem (or, Nut/OS version problem), but on
the other hand, the compiler settings is more anoying. If you have
boards with atmega and arm or atmega and uc3 (different boards,
different confs), then whenever you need to build for another board,
you need to change the compiler settings.

Kind Regards,
    Thiago A. Correa