experchange > linux.development.apps

Borneq (12-05-18, 04:20 PM)
I can't see make list on
I have download make source tarball and if I try compile I have error:
glob/libglob.a(glob.o): In function `glob':
/home/user/Downloads/make-4.2/glob/glob.c:581: undefined reference to
`__alloca'
glob/libglob.a(glob.o):/home/user/Downloads/make-4.2/glob/glob.c:732:
more undefined references to `__alloca' follow

I want compile it from sources bacause I ant prepare it do not rebuild
all after git commits.
Make has one big disadvatage: after git commit of project, whole project
is rebuild.
Tauno Voipio (12-05-18, 07:37 PM)
On 5.12.18 16:20, Borneq wrote:
[..]
> all after git commits.
> Make has one big disadvatage: after git commit of project, whole project
> is rebuild.


You may be barking up the wrong tree here: To force Make to rebuild
the whole kit and caboodle, GIT seeems to change the modification
timestamps of the files. It cannot be solved by changing Make.
Borneq (12-05-18, 08:02 PM)
W dniu 05.12.2018 o 18:37, Tauno Voipio pisze:
> You may be barking up the wrong tree here: To force Make to rebuild
> the whole kit and caboodle, GIT seeems to change the modification
> timestamps of the files. It cannot be solved by changing Make.


I think, git not changes timestamps of my *.cpp files on commit, only on
checkout (if I change branch)
Make looks to .git directory and timestamp of any git file is changed.
If I previously use ninja, no any *.cpp file was changes, buf "explain"
give me

EXPLAIN("recorded mtime of %s older than most recent input %s (%d vs %d)"...
and
EXPLAIN("command line changed for %s", output->path().c_str());

if I comment this, only changed *.cpp file was build
Rainer Weikusat (12-05-18, 08:18 PM)
Borneq <borneq> writes:
> W dniu 05.12.2018 o 18:37, Tauno Voipio pisze:
> I think, git not changes timestamps of my *.cpp files on commit, only
> on checkout (if I change branch)


git doesn't preserve file timestamps of versioned files, these get
whatever timestamp is current when being checked out. That's supposed to
be a feature. This can be problematic if some versioned files could also
be recreated by a Make-using build system: If the repository is large
enough or happens at a 'bad' time, the source files may end up being
newer than the generated files.
Tauno Voipio (12-05-18, 08:21 PM)
On 5.12.18 20:02, Borneq wrote:
[..]
> and
> EXPLAIN("command line changed for %s", output->path().c_str());
> if I comment this, only changed *.cpp file was build


Your makefile is bad, if it looks at or into .git directory.
Make should use timestamps of the dependencies only.
Borneq (12-05-18, 09:28 PM)
W dniu 05.12.2018 o 19:21, Tauno Voipio pisze:
> Your makefile is bad, if it looks at or into .git directory.
> Make should use timestamps of the dependencies only.


because
# The top-level source directory on which CMake was run.
CMAKE_SOURCE_DIR = /home/user/projects/project_name
?

project_name contains .git and several directories: app, lib, test..
Borneq (12-05-18, 10:30 PM)
W dniu 05.12.2018 o 19:21, Tauno Voipio pisze:
> Your makefile is bad, if it looks at or into .git directory.
> Make should use timestamps of the dependencies only.


I have created test project

after commit is rebuild whole project
what I might change?
I don't want moving all but .git to one directory src/
Tauno Voipio (12-05-18, 10:43 PM)
On 5.12.18 21:28, Borneq wrote:
> W dniu 05.12.2018 o 19:21, Tauno Voipio pisze:
> because
> # The top-level source directory on which CMake was run.
> CMAKE_SOURCE_DIR = /home/user/projects/project_name
> ?
> project_name contains .git and several directories: app, lib, test..


You did ask about GNU Make, which is NOT CMake.
Please do not change the target during discussion.

Try again with the real thing.
Rainer Weikusat (12-06-18, 01:07 AM)
Tauno Voipio <tauno.voipio> writes:
> On 5.12.18 21:28, Borneq wrote:
> You did ask about GNU Make, which is NOT CMake.
> Please do not change the target during discussion.
> Try again with the real thing.


He already mentioned that he was using CMake generated Makefile.
This suggests that the problem is really with CMake/ the way CMake is
being used, and that the "compile GNU make from source" was just a (very
likely wrong-headed) attempt at a solution.
Similar Threads