RE: [ECOS] config tools

["Dan Conti" <danc at iobjects dot com>]

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
>