This is the mail archive of the ecos-patches@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: FWD: Re: [ECOS] Accessing config parameters in define_proc code


>>>>> "Andrew" == Andrew Lunn <andrew.lunn@ascom.ch> writes:

    >> If a CDL script starts relying on new libcdl functionality we
    >> need to provide new binaries and get people to download and
    >> install them. Many people will ignore that request, and you can
    >> end up with people complaining about strange error messages.

    Andrew> I thought about that. My define_proc is inside an option,
    Andrew> which by default is disabled. You only need the modified
    Andrew> libcdl is you want to use the password protected redboot.
    Andrew> Even then, my tcl script does...

    Andrew> if {{} == [info commands get_value]} {
    Andrew>     puts stderr "Your version of libcdl is too old to support configurations"
    Andrew>     puts stderr "which include a fixed reboot password. Please either "
    Andrew>     puts stderr "upgrade/recompile your configuration tool, or disable option"
    Andrew>     puts stderr "CYGBLD_BUILD_REDBOOT_WITH_PASSWORD_FIXED."
    Andrew>     exit 1
    Andrew> } else {
    Andrew> ...
    Andrew> }

    Andrew> For ecosconfig, this works well. What i don't know is
    Andrew> where the output will go if you are using the GUI.

With a Unix build the output should go to either the console or to the
terminal window from which you started the tool. With the Windows
version the output would probably go to /dev/null. In theory the Tcl
script could use something like:

    if { 0 == [llength [info commands cdl_get]] } {
        error "Your version of libcdl..."
    }

That should end up as a C++ exception which will be caught by the
GUI code, which will display a message box containing the message.

OK, I'll spend some time tomorrow on this patch and try to rework it
such that it ends up with roughly the right TCL API, even though the
implementation will need more work later. That way I can avoid having
to support several different API's long term because of backwards
compatibility concerns.

Bart


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]