patch propagate PACKAGE_*

[Ralf Hemmecke]

Unfortunately, I haven't realized earlier that not all the PACKAGE_*
variables from configure made it into the Makefiles.
Sigh, we don't use automake.

Patch attached.

Ralf

[Waldek Hebisch]

What do you want to do? AFAIK we do not propagate variables
that we do not use. We make rather limited use of autotools
because otherwise we would get considerable bloat. Basically,
tactic in autotools is to propagate everthing (using a buch
of templates), regardless if this is needed or not for
specific project. That leads to problems with run time of
build machinery. And debugging problems when something goes
wrong. In FriCAS considerable effort went into _removing_
useless parts. So, if you really need some variable, then
add and use it. But adding variable only because autotools
has it make no sense.

Concerning PACKAGE_ stuff, part of it is bloat forced by
configure, few are used to print messages. If you want
new message, then add all code needed to support it.
But ATM the patch look incomplete...

--
Waldek Hebisch

[Ralf Hemmecke]

Hi Waldek,

> Concerning PACKAGE_ stuff, part of it is bloat forced by configure,
> few are used to print messages. If you want new message, then add
> all code needed to support it. But ATM the patch look incomplete...

OK, I feared that you will criticize that patch, so I first proposed it
on the mailing list.

I am currently work on putting all stuff for generating the book and
fricas.github.io into fricas so that everyone can generate the website
and also a local (offline) version of it. Of course, I can hardcode the
data that is already in configure.ac, but I don't like to double data.
You probably see that it makes sense to have also PACKAGE_NAME,
PACKAGE_BUGREPORT, and PACKAGE_URL available to show them in the
documentation.

Of course, that patch must look incomplete now, but I thought it's small
enough to go in before the big documentation patch.

That brings me to another question, before I spend even more time on it
and then get rejected...

Formerly, I used another (GPL) repository
https://github.com/hemmecke/fricas-doc to generate fricas.github.io, but
that looked unnecessarirly artificial to me, since I need the fricas
sources in order to generate book and website. The only information that
fricas-doc actually added was a few .rst files. So now I develop a
branch on top of fricas master with all the information and
build-machinery in it. Since I rebase and change commits quite a lot, I
have not proposed it yet officially, but if anyone wants to look and
criticize it, it is at:

https://github.com/hemmecke/fricas/commits/formatted

The last commits are rather messy... they will be cleaned up.

Anyway, the question is whether *you* like the idea of having code and
documentation/website in the same repository. Of course, I would like to
have it that way, because splitting docs and code doesn't make sense for
for me for our rather small repository and I wanted to avoid git
submodules or other stuff to sync the documentation and code versions.

Ralf

[Waldek Hebisch]

On Sun, Aug 30, 2020 at 09:06:08AM +0200, Ralf Hemmecke wrote:
> Hi Waldek,
>
> > Concerning PACKAGE_ stuff, part of it is bloat forced by configure,
> > few are used to print messages. If you want new message, then add
> > all code needed to support it. But ATM the patch look incomplete...
>
> OK, I feared that you will criticize that patch, so I first proposed it
> on the mailing list.
>
> I am currently work on putting all stuff for generating the book and
> fricas.github.io into fricas so that everyone can generate the website
> and also a local (offline) version of it. Of course, I can hardcode the
> data that is already in configure.ac, but I don't like to double data.
> You probably see that it makes sense to have also PACKAGE_NAME,
> PACKAGE_BUGREPORT, and PACKAGE_URL available to show them in the
> documentation.

OK.

> Of course, that patch must look incomplete now, but I thought it's small
> enough to go in before the big documentation patch.

Well, if this make things simpler for you, then go on. I find such
small changes more readible in context, that is as part of bigger
change.

> That brings me to another question, before I spend even more time on it
> and then get rejected...
>
> Formerly, I used another (GPL) repository
> https://github.com/hemmecke/fricas-doc to generate fricas.github.io, but
> that looked unnecessarirly artificial to me, since I need the fricas
> sources in order to generate book and website. The only information that
> fricas-doc actually added was a few .rst files. So now I develop a
> branch on top of fricas master with all the information and
> build-machinery in it. Since I rebase and change commits quite a lot, I
> have not proposed it yet officially, but if anyone wants to look and
> criticize it, it is at:
>
> https://github.com/hemmecke/fricas/commits/formatted
>
> The last commits are rather messy... they will be cleaned up.

In https://github.com/hemmecke/fricas-doc/Makefile I see somewhat
disturbing text:

# Out-of-source builds are not supported

> Anyway, the question is whether *you* like the idea of having code and
> documentation/website in the same repository. Of course, I would like to
> have it that way, because splitting docs and code doesn't make sense for
> for me for our rather small repository and I wanted to avoid git
> submodules or other stuff to sync the documentation and code versions.

Yes, I like to have code and documentation in the same repository.

> Ralf
>
> --
> You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/2b354a71-6354-2aaa-9fa0-2871a6e61fcd%40hemmecke.org.

--
Waldek Hebisch

[Ralf Hemmecke]

> In https://github.com/hemmecke/fricas-doc/Makefile I see somewhat
> disturbing text:
>
> # Out-of-source builds are not supported

Yes, but since fricas-doc is not going to be the target, it's
unimportant. That was how I collected part of the fricas.github.io data.

Of course the documentation patch will be tested for in-source and
out-of-source builds.

> Yes, I like to have code and documentation in the same repository.

Thanks. That makes things clear.

Ralf