search

stefanhaustein / TerminalImageViewer

Small C++ program to display images in a (modern) terminal using RGB ANSI codes and unicode block graphics characters
Other
1.56k stars 111 forks source link

Compile / Install: support for toplevel make? #94

Closed rubyFeedback closed 2 years ago

rubyFeedback commented 3 years ago

Hi there,

I noticed a makefile in a subdirectory for the C++ code. That's fine.

My question is: could a toplevel Makefile also be added? E. g. it could just call that other makefile perhaps. Not a big deal but I wanted to mention is.

Second part of the suggestion here: could --prefix also be supported? Also not a big deal, but I'd like to install tiv by default into /home/Programs/Terminalimageviewer/VERSION_HERE if possible. Again, not a big deal, I can manually relocate anyway via mv; or just use ruby to add/patch "make install" defaulting to this automatically, but I also wanted to mention the "poor man's variant solution" in case, for example, I want to install tiv at a computer without ruby installed. (Once ruby is installed I can download my gems anyway, but sometimes university computers don't have ruby, or only a very old ruby, then I have to do manual things; which is fine if it is only one or two projects, but if its lots of projects it's actually easier if these projects support flexibility in this regard, IMO).

rubyFeedback commented 3 years ago

I suppose the second variant is for DESTDIR or something like that.

aaronliu0130 commented 3 years ago
  1. The makefiles in the subdirectories is due to there being two seperate versions: C++ and Java. There's not much you could do with that other than creating a symlink.
  2. You seem to be under the illusion that only ruby can add/patch things. Ruby is NOT your solution to everything. There are so much other tools you can use other than ruby to solve the same problem. Allow me to help you with that.
aaronliu0130 commented 3 years ago

@rubyFeedback follow up plz

stefanhaustein commented 3 years ago

The Java version is included for historical reasons, I don't think it should block us from adding a toplevel makefile if that simplifies stuff

I am also not opposed to installation location support, but that's really a separate issue. Let's focus on the top level make in this issue.