[ECOS] config tools

[ECOS] config tools

[Dan Conti]

Hi,

I've noticed that "ecosconfig tree" errors out ungracefully if i have an
.ecc with the read only bit set. Is this intentional? I'm only using it
to build a tree, not modify the configuration, so this seems odd. It
tends to make the build directory but not populate it, and spew out a
variety of useless messages about inferred values (flipping on verbose
does not help to diagnose the problem). The ecosconfig i'm using is hand
built from the cvs snapshot i have.

Also, one problem with the gui tool (all versions). If I manually copy
an .ecc to a new folder on my hard drive, and open it with the config
tool, then go to build, it gets very upset because there is no build
tree. However, there is no way to get it to generate a build tree
without saving the .ecc. However, there is no way to save the .ecc
without changing a value in the .ecc, so the Configtool is convinced
that it actually needs to save. Combined with the fact that my .ecc
files have the read only bit set, it's all rather painful. Would it be
possible to have a menu option Build->Tree that would simply create the
build tree? :) Pretty please? My snapshot isn't from the tip otherwise i
would look at this myself.

Thanks,

-Dan


--
Dan Conti             e danc@iobjects.com
Software Engineer     p    (425) 289 0326

Re: [ECOS] config tools

[Julian Smart]

At 08:21 PM 8/9/01 -0700, Dan Conti wrote:
>Also, one problem with the gui tool (all versions). If I manually copy
>an .ecc to a new folder on my hard drive, and open it with the config
>tool, then go to build, it gets very upset because there is no build
>tree. However, there is no way to get it to generate a build tree
>without saving the .ecc. However, there is no way to save the .ecc
>without changing a value in the .ecc, so the Configtool is convinced
>that it actually needs to save. Combined with the fact that my .ecc
>files have the read only bit set, it's all rather painful. Would it be
>possible to have a menu option Build->Tree that would simply create the
>build tree? :) Pretty please? My snapshot isn't from the tip otherwise i
>would look at this myself.

That does seem like a reasonable thing to have, yes, so I'll add it to my 
ToDo list...

Thanks,

Julian
--
Red Hat UK Ltd, Unit 200 Rustat House, 62 Clifton Road, Cambridge, UK. CB1 
7EG Tel: +44 (1223) 271063

Re: [ECOS] config tools

[Bart Veer]

>>>>> "Dan" == Dan Conti <danc@iobjects.com> writes:

    Dan> I've noticed that "ecosconfig tree" errors out ungracefully
    Dan> if i have an .ecc with the read only bit set. Is this
    Dan> intentional? I'm only using it to build a tree, not modify
    Dan> the configuration, so this seems odd. It tends to make the
    Dan> build directory but not populate it, and spew out a variety
    Dan> of useless messages about inferred values (flipping on
    Dan> verbose does not help to diagnose the problem). The
    Dan> ecosconfig i'm using is hand built from the cvs snapshot i
    Dan> have.

Typically ecosconfig will attempt to write out an updated version of
ecos.ecc whenever you run it. The idea here is that if the user has
manually edited a configuration option, say CYGPKG_INFRA_DEBUG, then
this change should be reflected in the various places in the .ecc file
which are affected by that configuration option, for example the entry
for kernel thread stacking:

    cdl_component CYGFUN_KERNEL_THREADS_STACK_CHECKING {
        # This option is not active
        # ActiveIf constraint: CYGPKG_INFRA_DEBUG
        #     CYGPKG_INFRA_DEBUG == 0
        #   --> 0
        # ActiveIf constraint: CYGDBG_USE_ASSERTS
        #     CYGDBG_USE_ASSERTS == 0
        #   --> 0
        ...
    }

Hence the next time the user starts to edit the configuration the
savefile is an accurate representation of the current state. There
have been debates in the past about exactly which ecosconfig
operations should and should not cause an updated ecos.ecc file to be
written out, but no consensus.

So having a read-only ecos.ecc file is unexpected. However, I have
just tried a little experiment doing a chmod -w on ecos.ecc in an
existing build tree and it does not behave too badly:

    $ ecosconfig tree
    Unable to open file ecos.ecc
    couldn't open "ecos.ecc": permission denied

ecosconfig exits before updating the build tree, and the error message
is unclear that the problem is with write-access to the savefile so it
should be improved, but I do not see the strange behaviour you have
reported. If I try to run this in a new directory after copying across
an existing ecos.ecc I get the same error.

Bart

Re: [ECOS] config tools

[Bart Veer]

>>>>> "Dan" == Dan Conti <danc@iobjects.com> writes:

    <snip>

    >> Hence the next time the user starts to edit the configuration
    >> the savefile is an accurate representation of the current
    >> state. There have been debates in the past about exactly which
    >> ecosconfig operations should and should not cause an updated
    >> ecos.ecc file to be written out, but no consensus.

    Dan> This seems to all make sense, assuming the contents of the
    Dan> .ecc have changed. However, my configurations are being
    Dan> generated by the gui tool, so they dont need to be modified
    Dan> or updated.

Probably the best solution would be for ecosconfig to write to a
temporary file and then diff the new and old versions of ecos.ecc,
only overwriting the old version when necessary. Or even better,
construct the new copy in memory first.

    >> So having a read-only ecos.ecc file is unexpected. However, I
    >> have just tried a little experiment doing a chmod -w on
    >> ecos.ecc in an existing build tree and it does not behave too
    >> badly:
    >> 
    >> $ ecosconfig tree
    >> Unable to open file ecos.ecc
    >> couldn't open "ecos.ecc": permission denied
    >> 
    >> ecosconfig exits before updating the build tree, and the error
    >> message is unclear that the problem is with write-access to the
    >> savefile so it should be improved, but I do not see the strange
    >> behaviour you have reported. If I try to run this in a new
    >> directory after copying across an existing ecos.ecc I get the
    >> same error.

    Dan> I should explain now that i'm using cygwin (i just noticed i
    Dan> hadn't mentioned that). I'm using --no-resolve; if i turn
    Dan> that off, i get a spew of messages such as the following:

    Dan> U CYGSEM_KERNEL_SCHED_TIMESLICE_ENABLE, new inferred value 1
    Dan> U CYGBLD_ISO_STDIO_FORMATTED_IO_HEADER, new inferred value
    Dan> <cyg/libc/stdio/stdio.h>
    Dan> U CYGBLD_ISO_STDIO_FILEACCESS_HEADER, new inferred value
    Dan> <cyg/libc/stdio/stdio.h>
    Dan> U CYGSEM_KERNEL_SCHED_ASR_GLOBAL, new inferred value 1

Some of these look familiar: there was a problem in the GUI configtool
in that it was failing to resolve some conflicts that ecosconfig could
resolve automatically. Hence the savefile generated by the GUI was not
conflict-free, and ecosconfig resolves the problems. The most recent
version of the config tool has a fix for this. Note that these
messages are not errors, they are just informative messages to tell
you about changes in the configuration. The --quiet option should
suppress that output.

However if this is really what is happening then I would expect the
updated ecos.ecc file to be different from the original.

Bart

RE: [ECOS] config tools

[Dan Conti]

Hi Bart,

> -----Original Message-----
> From: Bart Veer [ mailto:bartv@redhat.com ]
> Subject: Re: [ECOS] config tools
> 
> Typically ecosconfig will attempt to write out an updated version of
> ecos.ecc whenever you run it. The idea here is that if the user has
> manually edited a configuration option, say CYGPKG_INFRA_DEBUG, then
> this change should be reflected in the various places in the .ecc file
> which are affected by that configuration option, for example the entry
> for kernel thread stacking:
> 
>     cdl_component CYGFUN_KERNEL_THREADS_STACK_CHECKING {
>         # This option is not active
>         # ActiveIf constraint: CYGPKG_INFRA_DEBUG
>         #     CYGPKG_INFRA_DEBUG == 0
>         #   --> 0
>         # ActiveIf constraint: CYGDBG_USE_ASSERTS
>         #     CYGDBG_USE_ASSERTS == 0
>         #   --> 0
>         ...
>     }
> 
> Hence the next time the user starts to edit the configuration the
> savefile is an accurate representation of the current state. There
> have been debates in the past about exactly which ecosconfig
> operations should and should not cause an updated ecos.ecc file to be
> written out, but no consensus.

This seems to all make sense, assuming the contents of the .ecc have
changed. However, my configurations are being generated by the gui tool,
so they dont need to be modified or updated.
 
> So having a read-only ecos.ecc file is unexpected. However, I have
> just tried a little experiment doing a chmod -w on ecos.ecc in an
> existing build tree and it does not behave too badly:
> 
>     $ ecosconfig tree
>     Unable to open file ecos.ecc
>     couldn't open "ecos.ecc": permission denied
> 
> ecosconfig exits before updating the build tree, and the error message
> is unclear that the problem is with write-access to the savefile so it
> should be improved, but I do not see the strange behaviour you have
> reported. If I try to run this in a new directory after copying across
> an existing ecos.ecc I get the same error.

I should explain now that i'm using cygwin (i just noticed i hadn't
mentioned that).
I'm using --no-resolve; if i turn that off, i get a spew of messages
such as the following:

U CYGSEM_KERNEL_SCHED_TIMESLICE_ENABLE, new inferred value 1
U CYGBLD_ISO_STDIO_FORMATTED_IO_HEADER, new inferred value
<cyg/libc/stdio/stdio.h>
U CYGBLD_ISO_STDIO_FILEACCESS_HEADER, new inferred value
<cyg/libc/stdio/stdio.h>
U CYGSEM_KERNEL_SCHED_ASR_GLOBAL, new inferred value 1

Using --ignore-errors doesn't seem to make any difference either. I've
also noticed that if i remove the read only bit, the timestamp on the
file is updated, but a diff reveals that nothing has actually changed.
In all cases it exits out, leaving a build directory with nothing in it,
and no install directory.

This is all scripted anyways, so i just put a chmod -w and a chmod +w
around the "ecosconfig tree" call and that seems to work fine. Just took
me a while to track this down, since i was looking for differences in
config tools instead of something this simple.

-Dan

> 
> Bart
>