search

AdaCore / gprbuild

GPRbuild is an advanced build system designed to help automate the construction of multi-language systems.
Other
65 stars 21 forks source link

Various issues with the Makefile #3

Closed Earnestly closed 4 years ago

Earnestly commented 8 years ago

I'm collecting a few issues as I find them here.

t-14 commented 8 years ago

The Makefile offers libexecdir=${exec_prefix}/libexec but then when stripping binaries the path is hardcoded

Thank you for pointing this out. Looks like a good candidate for a pull request ;)

Consequently it would be really nice if you didn't strip on the user's behalf

Just do "all"+"install" instead of "distall" if you want to inhibit stripping. But frankly -O2 wreaks so much havoc with flow control that debugging becomes a frustration. I would rather recommend switching BUILD scenario variable to "debug" if you want to do debugging.

The Makefile doesn't follow a simple $(DESTDIR)$(PREFIX)/... convention

Can you please elaborate? What is the convention? Thanks in advance.

Earnestly commented 8 years ago

The use of symbols on optimised builds is a strange notion I agree but having symbols can be a huge help when reporting issues with provided back-traces even if the control flow is surprising. It's at least a lot better than ??.

Cmake has a predefined build type called "RelWithDebInfo" for this purpose.

So for Makefiles. There has long being a convention of when installing to provide a DESTDIR variable. This was likely something from Debian or perhaps autotools but has been widely adopted by basically everyone still using Makefiles.

The idea is to have your normal PREFIX which always defaults to /usr/local and the DESTDIR to specify where you want the install to go. This lets you essentially define a custom root without hardcoding it in any expansions PREFIX might use.

A general form is:

PREFIX ?= /usr/local
...

install:
    install -Dm755 foobar $(DESTDIR)$(PREFIX)/bin/foobar

Now as a user I can use make DESTDIR=$HOME/local PREFIX=/usr install. The resulting tree can then be catalogued with tools like mtree(8), tarred up and packaged without the expansion of my $HOME polluting the build.

See https://www.gnu.org/prep/standards/html_node/DESTDIR.html for something a better explanation.

t-14 commented 8 years ago

Okay, thanks for the suggestions! It isn't as important in the gprinstall view of things since the prefix is not explicitly hardcoded in the generated project files, all references are kept relative to the project's root and so the deployed tree can be moved around without breaking any dependencies. But we didn't intend to have gratuitous difference from common conventions, so we will look into this.

Earnestly commented 8 years ago

Semi-relevant: http://www.standalone-sysadmin.com/blog/2014/03/just-what-we-need-another-package-manager/