Re: [ECOS] config tools

[Bart Veer <bartv at redhat dot com>]

>>>>> "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