[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Changes in mkdir definition cause problems

>>>>> "Ralf" == Ralf Corsepius <corsepiu at faw.uni-ulm.de> writes:

Ralf> VALETTE Eric wrote:
>> >>>>> "Ralf" == Ralf Corsepius <corsepiu at faw.uni-ulm.de> writes:
Ralf> VALETTE Eric wrote:
>> >> Previously MKDIR was defined as "/bin/mkdir -p"
>> >> now MKDIR is defined as "/bin/mkdir"
>> >>
>> >> Causing every Makefile that contains $(MKDIR) to fail.
Ralf> AFAIS, only the mcp750 BSP is affected :-.
>> >>
>> >> What is the rationale for the change and what is the correct
>> >> way to make it?
>> >>
Ralf> The rationale behind is further adaptation to automake standards:
Ralf> automake uses mkinstalldirs for "recursive mkdir" and "mkdir" for
Ralf> "non-recursive mkdir", because mkdir -p and mkdir -m XXX are not
Ralf> portable. Therefore the checks for mkdir -p, which we had in
Ralf> configure.in  and aclocal/mkdir.m4 until recently, now have been deleted
Ralf> and places where $(MKDIR) had been used before, have been replaced with
Ralf> either mkinstalldirs or mkdir.
>> If you use mkdir, then the second compilation will fail because the directory
>> exists which is a pain...

Ralf> In this case, either use
Ralf> test -d $(dir) || mkdir $(dir)
Ralf> or use
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??? 

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.

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...

-- eric