389673 - Fix "make install" to copy from dist/ rather than recursive makefile traversal

Status: RESOLVED FIXED

(Firefox Build System :: General, defect, P2)

Description

[Benjamin Smedberg]

"make install" currently traverses through all the built directories and uses install:: targets to install files. This is sucky, because we already have the files neatly laid out in dist/*. We should just copy the contents of the various dist/ directories to their proper installed locations. This also means that we can avoid "make install" breaking every other week.

This is important for the Linux FF-on-XR work, which will happen in the 1.9 timeframe for the distros.

Comment 1

[Benjamin Smedberg]

Attachment: Fix "make install", rev. 1

I think this everything I want. It follows a set of directory conventions similar to those I originally proposed in http://benjamin.smedbergs.us/blog/2006-03-27/building-the-xulrunner-sdk/ with some input from the Linux distro packagers: the headers, which are not arch-specific, are installed into prefix/include/<appname>/stable (frozen SDK headers) and prefix/include/<appname>/unstable (nonfrozen headers) and prefix/lib/<appname>/include is a symlink to the include directory. This fixes an issue that caillon had where arch-independent headers weren't supposed to end up in in dist/lib.

Comment 2

[(not currently active) Ted Mielczarek]

Comment on attachment 274304 [details] [diff] [review]
Fix "make install", rev. 1

>Index: toolkit/mozapps/installer/packager.mk
>===================================================================
>+install:: stage-package

The install target here is difficult to follow.  It would be nice if you added a comment block before it describing the directory structure it creates.

Comment 3

[Robert Kaiser]

This seems to have pulled a range of other small tweaks in, including e.g. parts of what I filed bug 386582 for...

What changes should other apps than Firefox do to sync up with all you've done here?

Comment 4

[Benjamin Smedberg]

Fixed on trunk. I have committed the necessary changes to suite/build.mk and mail/build.mk to have "make install" work for them. Until you get around to doing app-on-XR builds, the remaining changes are unnecessary.

Comment 5

[Johnny Accot]

Is it normal that the hierarchy of header files is lost in ${includedir}/stable and ${includedir}/unstable?  All my code uses things like <xpcom/nsAutoPtr.h>, <dom/nsIDOMElement.h>, etc., and it's all gone now.  I hope the hierarchy will be kept.  It's pretty messy to have hundreds of headers in one single directory, IMHO.

Comment 6

[Benjamin Smedberg]

That was intentional, though we could add back the module subdirs. The mozilla headers do not #include in that way though, they #include "nsCOMPtr.h" etc., so I don't know that keeping a separate convention for embedders doesn't seem to make much sense.

Comment 7

[cls]

History really does repeat itself.  See bug 59454 for why we split up the headers this time around.  I think those concerns are still valid.

IIRC, the only reason mozilla didn't support subdirs in #include is because some versions of codewarrior didn't recognize / as a path separator.  After that, it became part of the folklore. 

Comment 8

[Benjamin Smedberg]

Please note that this change does not affect the location of headers in dist/include/modulename... it only affects the location of installed headers.

Comment 9

[Alex Graveley]

xpidl is no longer being installed via "make install".  Is this patch the cause?

Comment 10

[Benjamin Smedberg]

Yes. Please file that as a separate bug... xpidl should come with the SDK but not the default app files.

Comment 11

[Sergey Yanovich]

installed xulrunner's footprint is up some 20Mb. The content of sdk/lib is essentially some libs from $(pkglibdir) plus xpcomglue. Symlinks are used for most directories in sdk.

May be symlinks will work in sdk/lib for non-glue libs as well?

Comment 12

[Sergey Yanovich]

Upon closer investigation, there are only two libs in $(sdkdir)/sdk/lib, which are not in $(pkglibdir). If these libs are moved to $(pkglibdir), sdk/lib can become a symlink to $(pkglibdir).

In turn, the whole $(sdkdir) dir becomes a bundle of symlink then. It becomes possible to pack the whole $(sdkdir) together with pkg-config files, idl files and headers in a platform independent xulrunner-devel package. This platform independence of sdk will be a considerable save of efforts for linux distributions, and will contribute to penetration of mozilla platform.

Comment 13

[Benjamin Smedberg]

The static libraries should only be in the -devel package, not in the ordinary runtime package. If you would like to use symlinks for the .so files that are shared, please file a separate bug and provide a patch.

Comment 14

[Johnny Accot]

With regard to my previous comment (#5), should I file a new bug?

Because I need the hierarchy of header files, I'm stuck with xulrunner-1.9a6 and I'd really like to be able to move along with the trunk.  My request is not based on my self-interest though.  I truly think that most embedders would like the hierarchy to be kept — just like mozilla developers would like the hierarchy to be kept in dist/include.

The advantage of a hierarchy is that if one wants to #include "nsCOMPtr.h", they can add -I$(includedir)/xpcom to their CPPFLAGS, *or* they can #include "xpcom/nsCOMPtr.h" with no extra include path.  They have a choice.  When there is no hierarchy, there is no choice and one has to #include "nsCOMPtr.h".  There is no CPPFLAG that can strip off the path in my source code.  In my case (and for others I'm sure), this means I have to scan through all my code and remove the include paths, which is a loss of valuable information.  I want to know how my code depends on mozilla's modules and if I wanted to use the new include scheme, I would have to give up that information.  Losing information is never good.

Is it worth filing a new bug then?  The problem is that, until other people make their voice heard, there won't be any reason to choose between having a hierarchy or not, such that the bug will hang around as unresolved for a long time.

Comment 15

[Benjamin Smedberg]

Well, I don't think additional commentary in this bug will help much. I'm not convinced that mozilla's include modules are at all useful. You could also bring it up in one of the newsgroups.

Comment 16

[Serge Gautherie (:sgautherie)]

http://hg.mozilla.org/mozilla-central/rev/075a4c00be7b