[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Changes in mkdir definition cause problems
- Date: Mon, 12 Jul 1999 08:59:02 -0500 (CDT)
- From: joel at OARcorp.com (joel at OARcorp.com)
- Subject: Changes in mkdir definition cause problems
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
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.