make is a utility for end users or for programmers/developers?

Very good!!!

But I think there would be a post to review


You can see some parts in red, and in general there are some salient parts of this discussion.


You can see that you can keep everything under control, and you don't have my problem of biting your tail.

Reread https://www.linux.org/threads/make-...for-programmers-developers.53813/#post-250499

Just here is the matter (let's keep it in mind).

Wouldn't it be appropriate to at least give some comments/answers?

Otherwise the discussion will remain largely inconclusive.
 
Last edited:


Very good!!!

But I think there would be a post to review


You can see some parts in red, and in general there are some salient parts of this discussion.




Wouldn't it be appropriate to at least give some comments/answers?

Otherwise the discussion will remain largely inconclusive.
I've already given you an option that best suits you lack of time/willingness to use anything complex. I even posted an educational PoC script which you refined somewhat, so you get the gist of using manual versioning. It's up to you now to deploy it.
 
The docker link you suggested, leads to other links

https://docs.do cker.com/get-started/docker-concepts/building-images/build-tag-and-publish-an-image/
https://docs.docker.com/get-started/docker-concepts/running-containers/persisting-contain er-date/
✅https://docs.docker.com/get-started/introduction/develop-with-containers/
✅https://docs.docker.com/get-started/introduction/build-and-push-first-image/
✅https://docs.docker.com/get-started/introduction/whats-next/
✅https://docs.docker.com/trusted-con tent/official-images/
✅https://docs.docker.com/trusted-content/official-images/using/
✅https://docs.docker.com/trusted-content/official-images/contributing/
✅

and more.
I've read the ones checked.
I'll read the others; time will tell.

In addition to what I've already acquired, could I find something interesting?

I also hope to find the explanation to try to understand what is wrong...
https://www.linux.org/threads/make-...-for-programmers-developers.53813/post-250809 (see the first part)

Anyway, I repeat, time permitting, I'm trying to keep busy.
 
Last edited:
In addition to what I've already acquired, could I find something interesting?

Yes?
No?
Maybe?
Who knows...

I also hope to find the explanation to try to understand what is wrong...
https://www.linux.org/threads/make-...-for-programmers-developers.53813/post-250809 (see the first part)

Hope.
I'm continuing to document myself, but for the moment no confirmation.
Is it worth continuing?

Anyway, I repeat, time permitting, I'm trying to keep busy.

Honestly, I'm starting to get a little tired.

Anyway


Could this be helpful?


I didn't understand much, but could this be helpful?

And then there would be this very long page to read


and then more, and then more.

I have the impression that I'm reading an encyclopedia, to solve a trivial problem.

Any more targeted suggestions or examples, no?
 
Unfortunately if you onboard any new technology, it's best to gain a comprehensive understanding first. I personally found it was a better ROI on time to stick with what I had, which at the time was a small set of utility scripts, for my own projects. When collaborating on Tainted Skies, the team went with git, so that decision was made for me, lol. In later years I found using a cloud service with versioning was easiest. So it boils down to the long run, too. Some technologies, like Docker, have other uses like isolated environments which allows you to deploy things without messing with your system, and in a way that makes life more portable. If you feel overwhelmed, set smaller goals. Be able to use a container. Then be able to maintain containers, and so forth. It's important to take breaks from the reading and focus on the doing, even if the doing isn't much. It's a lot like getting into Linux or learning any skill, even things like woodwork or cooking.

I'll suggest again that you check out Youtube. Not all tutorials are equal but the info is more condensed and focuses on teaching you pragmatics. So long as you learn from multiple sources so you have different perspectives, which helps you figure out best practices.
 
Make is a very handy tool along with configure In the old days 1990's you had no choice with many programs as they just were not compiled for may Distros. So you had to install them using make.

OK

As pointed out today there are many alternatives and you can find most programs that are not compiled for a distro's repositories as an appimage, flatpack or snap. And avoid having to make it.

mmmhhh... could you explain yourself a little better?
 
OK



mmmhhh... could you explain yourself a little better?
Well most programs you desire to use today all ready come in some usable format. So you can avoid using make, but someone along the line at some point in the process had to build the desired program for use by the end user to conform to the distros or Cross platform Media (appimage, flatpack or snap) During that process of building Make is most likely used at some point. The Fact that end users to do not often see this work. But there are occasions still that require one to use tools like configure and or make and make install to make a particular program work on your distro of choice. I'll admit it's not aa prevalent as it used to be and That is a good thing for many people.
 
Make's purpose is to build a project by compiling only those source files that have changed since the previous build, resolving dependencies along the way, according to well defined rules (with a sane set of default rules).

PREMISE

Is it a good idea to use two separate directories (development directory and production/compiling/building directory)?

Here is a concrete example

Code:
# SOURCE     : dev       (the development directory)
# DESTINATION: ../prod   (the production/compiling/building directory)

+ cd dev

+ rsync \
	-a \
	--exclude makefile \
	--exclude a \
	--exclude b \
	--delete \
	--delete-excluded \
	. \
	../prod

+ find
./makefile
./b
./a

+ cat makefile
test1:
	cat a b > x
test2:
	cat ${SRC}/a ${SRC}/b x

+ make \
	-f $PWD/makefile \
	-C ../prod \
	test1
+ make: Entering directory '/tmp/tmp.acvquFbBZk/prod'
cat a b > x
cat: a: No such file or directory
cat: b: No such file or directory

mmmhhh...
Let's try again with <B>test2</B>

Bash:
+ make \
	-f $PWD/makefile \
	-C ../prod \
    test2
make: Entering directory '/tmp/tmp.acvquFbBZk/prod'
cat /a /b x
cat: /a: No such file or directory
cat: /b: No such file or directory

mmmhhh... it doesn't work, maybe because, in reality, the variable ${SRC} doesn't exist: I abandoned myself to my intuition...

So how to solve?

Anyway, as already said at the beginning, Is it a good idea to use two separate directories?
Or, especially if you use make command, is it better to do everything in one directory (have source files and compiled files in a single directory)?

PS

I don't understand much English and I don't speak English, so try to answer calmly and clearly.
One question at a time, one answer at a time; but at the same time try to answer all the questions.
Let me understand the concepts well!!!
Calm down, calm down, examine carefully what I wrote, and then calmly answer, otherwise I am forced to always ask for further explanations.
 

Members online


Top