PR469 IDE problem, was: Re: Any New 4.6.4 Issues

[Ralf Corsepius]

On Fri, 2005-09-16 at 08:42 +0200, Thomas Doerfler (nt) wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hello Ralf, and good morning,
> 
> Ralf Corsepius schrieb:
> > On Fri, 2005-09-16 at 07:12 +0200, Thomas Doerfler (nt) wrote:
> >>Ralf, I would assume that there is a better way to set these options,
> >>e.g. when "configure" is given. I added definitions for these options in
> >>the bsp's "configure.ac" file, so I assume there is a predefined way to
> >>modify these options....
> > 
> > I don't understand.
>   ^^^^^^^^^^^^^^^^^^
> That's what I have feared... It is still early morning here
Same here.

>  (at least
> for me)
Not for me ;)

>  and therefore I think I should go more into details.
> 
> Preface: I still have only a slight clue what autoconf/automake is
> doing. 
In a nutshell:
* autoconf isn't much more than an extended "sed" that processes user
provided configuration options into sed substitutions.
* automake isn't much more than a scheme to write Makefiles, which
autoconf fills sed substitutions.

I.e. from a very high level perspective, all autoconf does is to edit
Makefiles and other files from input originating from several sources,
such as user provided input (configure arguments), hard-coded knowledge
(configure script) and the result of processing both.

> Although my inpression is, whatever it is doing it does perfectly
> well and configuring/building RTEMS without it would be VERY diffcult.
> 
> When I added the two configuration options yesterday for the PC386 BSP,
> I have done the following:
> 
> 1. I added two "#if IDE_USE_PRIMARY/SECONDARY_INTERFACE" sections to
> 
> "c/src/lib/libbsp/i386/pc386/ide/idecfg.c"
> 
> so now optionally the configuration structure(s) for a primary and/or
> secondary IDE interface can be enabled and disabled.
> 
> 2. I have added some lines to "c/src/lib/libbsp/i386/pc386/configure.ac"
> 
> - -------snip
> RTEMS_BSPOPTS_SET([IDE_USE_PRIMARY_INTERFACE],[*],[1])
> RTEMS_BSPOPTS_HELP([IDE_USE_PRIMARY_INTERFACE],
> [Determines, whether RTEMS will try to use the primary IDE interface.
>  Disable it, if:
>  - you have no primary IDE interface
>  - or you have no disk attached to this interface
>  - or you do not want to access disks attached to this interface])
> 
> RTEMS_BSPOPTS_SET([IDE_USE_SECONDARY_INTERFACE],[*],[0])
> RTEMS_BSPOPTS_HELP([IDE_USE_SECONDARY_INTERFACE],
> [Determines, whether RTEMS will try to use the primary IDE interface.
>  Enable it, if:
>  - you have a secondary IDE interface
>  - and you have at least one disk attached to this interface
>  - and you do want to access disks attached to this interface])
> - -------snip
Without having checked all details, this seems to be the way how things
currently are supposed to work.

> 3. Now I assume, that a "bootstrap" will generated/update the
> i386/pc386/include/bspopts.h.in and adds two "#undefs" for the new
> options (I could very this)
Yep.

> 4. Now the foggy stuff starts for me: The next steps for using RTEMS
> with this BSP are to configure a build tree and to perform a make there.
>  I do it with something like:
> $> mkdir build-rtems-4.6.99.2-i386
> $> cd build-rtems-4.6.99.2-i386
> $> ../rtems-4.6.99.2/configure --enable-rtemsbsp=pc386 \
> - --target=i386-rtems4.7 --prefix=/opt/rtems/4.6.99.2    \
> - --exec-prefix=/opt/rtems/4.6.99.2
> $> make all
>
> During these steps, the file
> build-rtems-4.6.99.2-i386/i386-rtems4.7/c/pc386/lib/libbsp/i386/pc386/include/bspopts.h
> 
> is created, and it will contain the defaut setting for the new options,
> as defined in the pc386/configure.ac file:
Note what you wrote: ".. will contain the default setting .."

> #define IDE_USE_PRIMARY_INTERFACE 1
> #define IDE_USE_SECONDARY_INTERFACE 0
>
> AND NOW MY QUESTION COMES UP:
> 
> My assumption is, that somewhere on the _command_lines_ for configure or
> make I could specify, that these options should be set differently, e.g.
> that configure and/or make will generate a different bspopts.h with
> settings other than the default settings specified in "configure.ac". If
> this is not possible, what would be the reason to put these options into
> "configure.ac" and not directly into "bspopts.h.in"?
> 
> E.g. Angelo's hardware will require these settings:
> 
> #define IDE_USE_PRIMARY_INTERFACE 0
> #define IDE_USE_SECONDARY_INTERFACE 1

=> he wants "non-default settings".

This means he will want to explicitly override them.

As things currently are implemented, he should be able to so by
overriding them from the environment:

../configure --enable-rtemsbsp=pc386 \
--target=i386-rtems4.7 \
--prefix=<whatever> \
IDE_USE_PRIMARY_INTERFACE=1 \
IDE_USE_SECONDARY_INTERFACE=0

If his BSP was part of the official sources, we could even hard code
this into the configure script:
RTEMS_BSPOPTS_SET([SOMEOPTION],[angelopc386],[1])
RTEMS_BSPOPTS_SET([SOMEOPTION],[*],[0])
RTEMS_BSPOPTS_HELP([SOMEOPTION],
[Some explanation])

BTW: Shouldn't these options be mutually exclusive or be integer values.
(IDE_INTERFACE={0,1,2} or similar).

> Ralf, I hope I could clarify my question to you. If I am still totally
> on the wrong track,
You ain't ;)

Ralf