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

Changes in mkdir definition cause problems



joel at OARcorp.com wrote:

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

One of my next patches addresses this problem.

Instead of creating the directories in c/Makefile.in, they are created during the
preinstall stage in decentralized location in various Makefiles. I.e. in general the
directories are created using mkinstalldirs just before the files gets copied.

E.g.

include/<dir>/<subdir>/Makefile.in

will contain something similar to

MKINSTALLDIR= $(SHELL) $(RTEMS_ROOT)/mkinstalldirs
INSTALLDIRS=dir1 dir2

preinstall:
    $(MKINSTALLDIRS) $(INSTALLDIRS)
    $(INSTALL_CHANGE) -m644 $files1 $dir1
    $(INSTALL_CHANGE) -m755 $files2 $dir2

This is not yet completely automake-style, but is a working compromise for RTEMS
autoconf Makefile.ins.

Unfortunately this is part of another very large patch, of which I am not sure when
or if it will be integrated into the source-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.
>

Also note that mkinstalldirs has capabilities similar to INSTALL_CHANGE.

E.g..
* directories are only created if the directory does not yet exist.
* Supports setting permissions. This is necessary for RTEMS, because the temporary
installation tree RTEMS uses during the build process, later gets copied by invoking
tar which keeps the permissions the installer has had in its umask.  If built RTEMS
as root and use restrictive umasks and permissions would not be explictly set,
others probably will not be able to access an RTEMS installation.

Ralf.

--
Ralf Corsepius
Forschungsinstitut fuer Anwendungsorientierte Wissensverarbeitung (FAW)
Helmholtzstr. 16, 89081 Ulm, Germany     Tel: +49/731/501-8690
mailto:corsepiu at faw.uni-ulm.de           FAX: +49/731/501-999
http://www.faw.uni-ulm.de