search

PRUNERS / FLiT

A project to quickly detect discrepancies in floating point computation across hardware, compilers, libraries and software.
Other
36 stars 6 forks source link

Add DESTDIR variable to FLiT's Makefile #292

Closed mikebentley15 closed 4 years ago

mikebentley15 commented 4 years ago

Feature Request

Describe the new feature: When installing, apparently the PREFIX variable within the Makefile is not sufficient for some things. Specifically, I was looking at creating deb packages for Debian-based systems.

We would add another DESTDIR variable that would be before the PREFIX variable. The difference between them is that from the files that are installed, the DESTDIR should be the location of the root directory (i.e., /). Even absolute paths should be relative to DESTDIR.

Suggested change: Rework the top-level Makefile to use DESTDIR, and add some tests to test its functionality.

Alternative approaches: Don't use any absolute paths at all and only do relative paths. That way, we can simply prepend DESTDIR in front of PREFIX and no other work is necessary.

IanBriggs commented 4 years ago

I'm unfamiliar with the purpose of DESTDIR, and it looks like the description from bsd matches with the alternative approach.

Is there a reason we wouldn't want to use the alternative approach?

mikebentley15 commented 4 years ago

There are some placed in our installation that we use absolute paths, such as in the autogenerated flitconfig.py (that has paths to the pieces of the installation). We could change all of those to be relative paths instead.

I found out about DESTDIR when trying to make a Debian package containing FLiT. They use the DESTDIR as a root for the installation and PREFIX to be the base of the installation. If the installation uses absoolute paths, the absolute paths need to not include DESTDIR.

Another way to think about it is that we want to install into ~/install/ with a prefix of /usr/. We could then do a chroot into ~/install and use the software perfectly fine. Does that make sense?

I am fine with the alternative approach. It would probably make our package a little more robust. For example, if you install into a PREFIX, then decide you wanted it installed somewhere else, you can just move all of the files to a different directory and it would work just fine (as long as you kept the same directory structure).

Yeah, I like the idea of using the alternative method. Thanks for your input :)