Questions on FriCAS make

[riccard...@gmail.com]

Dear all

I have some simple (and non-urgent) questions on the use of toplevel make. Thanks in advance for your time and sorry if the questions may look trivial to you.


In the following I fix:

InstallDir=/path/to/install_dir
BuildDir=/path/to/build_dir
SysOptions= a bash array containing configure options NOT including --prefix and other options setting the target paths/files.


0)
Is there a toplevel ``make help`` that explains its options and their semantics?


1) Does ``make`` implies ``make check``?


2) Questions on safe cleaning before a rebuild.

Suppose that at time t0 I execute:

cd $BuildDir && configure --prefix=$INSTALL "${SysOptions[@]}" && make && sudo make install.

Then at time t1 > t0 I want to rebuild (maybe the sources changed, maybe not) and I execute

cd $BuildDir && configure --prefix=$INSTALL "${SysOptions[@]}" && make && sudo make install

1.1 Will the second ``make`` properly delete all the previous fricas-related contents in $InstallDIr or shall I manually delete them before?

1.2 Will the second ``make install`` properly delete all the previous fricas-related contents in $BuildDir or shall I manually delete them before?

1.3 May I omit ``configure --prefix=$INSTALL "${SysOptions[@]}`` (same parameters!) in the second build?



3) From https://github.com/fricas/fricas/blob/master/Makenotes.tex#L59

``The build system is set up so that if [[make all]] just completed
then [[make install]] will not modify any file in the build directory,``

is this still correct?


4)
Does ``make`` implies ``make all``?


5) From https://github.com/fricas/fricas/blob/master/Makenotes.tex#L821

``
[[mostlyclean]] acts almost like [[clean]] except that it does not
delete some files that are time-consuming to make (if remaking is
not needed), e.g. [[libspad.a]] or [[lisp]].

[[clean]] deletes any file created by running [[make]].
``

is this still correct?


6) From https://github.com/fricas/fricas/blob/master/Makenotes.tex#L821

``
[[distclean]] cleans up the build directory to the point where it almost
reverts to the state of the build directory before the initial build.

In summary [[clean]] can be interpreted as a prerequisite of [[distclean]],
and [[mostlyclean]] a prerequisite of [[clean]].

``

I'm confused: if clean deletes all files created by make and is a prerequisite of distclean, what actually does in addition distclean and what means ``almost`` in ``almost reverts to the state of the build directory before the initial build.''?


7)
Does ``make`` implies ``make clean`` or maybe ``make distclean``?

Does ``make`` implies ``make distclean``?


8) Are there any other important ``make`` targets that could be useful to a user / low profile developer workflow?

[riccard...@gmail.com]

PS Question 2 without some misprints (sorry!):

2) Questions on safe cleaning before a rebuild.

Suppose that at time t0 I execute:

cd $BuildDir && configure --prefix=$InstallDir "${SysOptions[@]}" && make && sudo make install.

Then at time t1 > t0 I want to rebuild (maybe the sources changed, maybe not) and I execute

cd $BuildDir && configure --prefix=$InstallDir "${SysOptions[@]}" && make && sudo make install

2.1 Will the second ``make`` properly delete all the previous fricas-related contents in $BuildDir or shall I manually delete them before?

2.2 Will the second ``make install`` properly delete all the previous fricas-related contents in $InstallDIr or shall I manually delete them before?

2.3 May I omit ``configure --prefix=$InstallDir "${SysOptions[@]}`` (same parameters!) in the second build?

[Waldek Hebisch]

On Fri, Mar 19, 2021 at 08:26:32PM +0100, riccard...@gmail.com wrote:
> PS Question 2 without some misprints (sorry!):
>
> 2) Questions on safe cleaning before a rebuild.
>
> Suppose that at time t0 I execute:
>
> cd $BuildDir && configure --prefix=$InstallDir "${SysOptions[@]}" && make && sudo make install.
>
> Then at time t1 > t0 I want to rebuild (maybe the sources changed, maybe not) and I execute
>
> cd $BuildDir && configure --prefix=$InstallDir "${SysOptions[@]}" && make && sudo make install
>
> 2.1 Will the second ``make`` properly delete all the previous fricas-related contents in $BuildDir or shall I manually delete them before?

I think there is some misconception in this question. Namely, "make"
is supposed to do _minimal_ recompilation/rebuild, avoiding
recompiling things that do not change (or possibly change in
inessential way (like date of file)). Of course "make" itself
does not know what is needed, so it must be told what to do
by giving it appropirate rules which roughly are of sort
"if date/time of file A has is newer than date/time of file B,
then run specifiled command". Those rules are collected in
Makefiles.

Assuming that our Makefiles work correctly there is no need
to delete anything produced by previous run of "make"
before next run. Having said this, various corner cases
there get very little testing so bugs are possible.

> 2.2 Will the second ``make install`` properly delete all the previous fricas-related contents in $InstallDIr or shall I manually delete them before?

Again, running "make install" multiple times is supposed to work.

> 2.3 May I omit ``configure --prefix=$InstallDir "${SysOptions[@]}`` (same parameters!) in the second build?

If you have the same parameters it is better to omit "configure"
part.

--
Waldek Hebisch

[Waldek Hebisch]

On Fri, Mar 19, 2021 at 07:31:51PM +0100, riccard...@gmail.com wrote:
>
> 8) Are there any other important ``make`` targets that could be useful to a user / low profile developer workflow?

All "make" targets that I expect user to use are in INSTALL
file:

make
make MAYBE_VIEWPORT=viewports
make viewports
make install

There is also "make check", it is important but I expect
(maybe wrongly) normal users to skip it. Then you have

make all-input

that I use for testing. Concerning "low profile developers",
I expect most of FriCAS developement to be done independently
of "make". So "make" targets are important only for final
testing. Note that adding files in normally can be done by
adding file names to appropriate lists of files in Makefile-s.
Of course some people will want to modify Makefile-s, then
you need to understand how "make" works and look at comments
in Makefile-s.

Concerning your other questions: "make" essentially is a
programming language which exposed internals of program
(that is Makefile) to the users. So the right question
is not "what make will do if I do some weird command?"
The right question is "how do I archive effect X?", where
X is one of things normally done with "make". Note
that many "make" targets are to support packagers
and FriCAS tries to follow common practice there,
in particular relevant parts of GNU coding standards.

--
Waldek Hebisch

[Ralf Hemmecke]

> Concerning "low profile developers",
> I expect most of FriCAS developement to be done independently
> of "make".

:-(

Why do you expect that? Because that is your development style or
because the build system is not smart enough to only compile the stuff
quickly that a developer changed?

Thanks to Qian we have CI working at github, so how local development
happens is mostly to the taste of the developer. Still, it would be
better if the build system was clever enough to just do the right thing
when one (re-)types "make".

Ralf

[Waldek Hebisch]

1) IME even in projects heavily geared toward "make" much of
developement was independent of "make". Namely, it was
running program under debugger, trying various tests and
observing state. Only after collecting enough data it
was possible to write code fixing a bug or implementing
new functionality.
2) Our algebra build have to solve bootstrap problem. Due
to this it is hard to avoid rebuilding whole algebra
after seemingly trivial change. Developer should have
reasonably good idea if change requires rebuilding
other files. "make" sees only file date/time and with
this must act conservatily and rebuild a lot.
3) Beside rebuild time, there is also problem of test data
and command line history. "gdb" keeps some testing
state (breakpoints, etc) and command line history and
picks new new executable after change. Lisp works by
loading changed code, which is nice but does not fit
well with "make". By recompiling file that I work on
I can keep my testing state in Lisp image and get
reasonably fast developement cycle: most time is my
thinking time, biggest delay is Spad compilation
which for single file is usually short enough to
not disturb thinking. From that point of view
"make" (or ruther time spent running it) is a cost,
which most projects must pay, but fortunately we do
not have to.

BTW: I suspect that Python folks also are less eager to
run "make" (OTOH Python bytcode compilation means that
make can be quite fast).

--
Waldek Hebisch