Changes in mkdir definition cause problems

[joel at OARcorp.com (joel at OARcorp.com)]

On Mon, 12 Jul 1999, VALETTE Eric wrote:

> Ralf> $(SHELL) $(RTEMS_ROOT)/mkinstalldirs $(dirs)
> 
> Why should I write that in every makefile instead of using a correct definition
> of MKDIR in a single Makefile??? 

This is the preferred autoconf/automake way of doing things. 

AIR MKDIR is from the RTEMS specific rules that are being (slowly)
obsoleted in favor of GNUitically correct ways of doing things.

> For me the purpose of a compilation environment is to help the user
> predefinning a lot of usefull stuff. Now you acknowledge that MKDIR is
> unusable in a Makefile.in. I say that is bad : I think, as a
> developper, I have the right to try to structure my BSP include files
> by creating sub-directory to regroup files instead of having a flat
> tree

The RTEMS way of obsoleting something is to fix every occurence of it in
the tree and normally fixing before you knew it was broken. :)

THis being a new BSP, it was missed.  

Traditionally, directories in the install point have been created by
c/Makefile.in so this case is handled more easily.   I don't know if this
will continue but it is the way it is.   I actually moved the MKDIRs from
the libcpu tree.

The only usage of the MKDIR command was in the mcp750 BSP.  I think it can
safely be removed.

> I was using MKDIR to achieve this. If you think this is a bad way, provide
> something else provided I can create sub directories for includes on a 
> BSP basis...
> 
> The -p mkdir option availability could be tested by autoconf test...

And if it is not supported, then what?

The mkinstalldirs is the preferred way of handling this. 

--joel