Ggradebook; request for assistance

[Norbert de Jonge]

Hi,

Last Monday, I released version 0.92 of Ggradebook (GNU gradebook), an
application to record student grades.

Announcement, including a download link:
http://lists.gnu.org/archive/html/ggradebook-devel/2017-02/msg00001.html

I hope to get help from a fellow GNU volunteer.
See point #2 in the announcement linked above.

More precise, to put it bluntly, I hope someone is willing to complete
this entire task for me. If substantial changes are required, I will
gladly update future releases to include an additional contributor
entry in the package's docs/AUTHORS.txt file.

I have no plans to read autoconf/automake documentation - or look at
related examples - myself. There are people who are skilled at, want to
learn more about, and help by, programming. Others focus on build
automation. Some both. I'm ('just') a programmer.

Obviously, I'd be grateful if you could help.

The inclusion of autoconf/automake files in GNU packages makes sense
and I hope it can be (re)added to Ggradebook. But at the same time it's
not a task I want to take on.

I hope this is not an unreasonable request. (I wonder if it is unusual.)
The task should be way easier for someone who is familiar with the
tools. Its current Makefile should contain all information required to
take on this task. Keeping the top level uncluttered, as I suggested in
my announcement, might be a slight challenge.

Best regards,
Norbert

[Norbert de Jonge]

Hi,

The following is my reply to someone who recently sent me an e-mail
with a modified Ggradebook 0.92 that includes autoconf/automake.

First of all, I sincerely appreciate you looking into it.

What you've created is not quite what I'm looking for.

Please (re)read point #2 in my announcement:
http://lists.gnu.org/archive/html/ggradebook-devel/2017-02/msg00001.html

I would like the top level (root directory) to be empty. What
autoconf/automake normally do is mess up the top level. These build
tools require many different (separate) files, and as a result this
programming tool starts dominating - it takes over - the entire package
with its crap. It's very ugly, in my opinion. If all its files cannot
live in their own auto/ directory or something similar, and then
address (talk to) 1 or 2 files in the other directories to get work
done, then I don't want autoconf/automake. Currently, the package uses a
simple Makefile in the src/ directory, and with the exception of "make
install" it's doing the job. I don't want autoconf/automake to make a
mess of this package. It should be happy that I'm willing to give it
its own directory and gets more than a single file. :)

Also, I would like the user to get a warning if their GTK+ or GStreamer
version is _newer_ than what is targeted. GTK+ in particular is a
library that has the potential to create compatibility issues, and
it deprecates functions constantly. I want users to know that any kind
of warnings the application is throwing, or any unintended behavior its
displaying, _may_ be the result of non-matching library versions. My
simple Makefile has a decent implementation of this.

Another problem with your package is the following. This program has
directories with content that it relies on. These directories are
docs/, ogg/ and pix/. If a user runs "make", the executable should be
moved into the parent directory for it to find files in those
directories.

Related to this, and equally important, is that "make install" should
take into account the aforementioned directories and that PKGDATADIR in
the source code should (thus) be respected. In the package you sent me,
there are no autoconf/automake related files in, for example, the ogg/
directory. This suggests to me that autoconf/automake ignores this
directory. I can confirm this suspicion by running "make install",
running the program and then selecting "Help..." from the application's
Help menu. It cannot find the docs/README.txt file.

One last thing. Perhaps autoconf/automake requires this, but... The gcc
commands appears to look for header files in directories that I'm
unfamiliar with. Including, but not limited to,
"/usr/include/at-spi-2.0", "/usr/include/dbus-1.0",
"/usr/include/gio-unix-2.0/", "/usr/include/mirclient" and
"/usr/include/harfbuzz". I'm certain that at least some of those
are not used with my Makefile. Maybe configure.ac is adding unnecessary
headers? I don't know enough about the tool to be sure.

I'm aware that I'm asking for a lot. Especially considering that I'm
hoping someone else will take on and finish this task in its entirety.

Best regards,
Norbert

[Russell Shaw]

Post by Norbert de Jonge
Hi,
The following is my reply to someone who recently sent me an e-mail
with a modified Ggradebook 0.92 that includes autoconf/automake.
First of all, I sincerely appreciate you looking into it.
What you've created is not quite what I'm looking for.
http://lists.gnu.org/archive/html/ggradebook-devel/2017-02/msg00001.html
I would like the top level (root directory) to be empty. What
autoconf/automake normally do is mess up the top level. These build
tools require many different (separate) files, and as a result this
programming tool starts dominating - it takes over - the entire package
with its crap. It's very ugly, in my opinion. If all its files cannot
live in their own auto/ directory or something similar, and then
address (talk to) 1 or 2 files in the other directories to get work
done, then I don't want autoconf/automake. Currently, the package uses a
simple Makefile in the src/ directory, and with the exception of "make
install" it's doing the job. I don't want autoconf/automake to make a
mess of this package. It should be happy that I'm willing to give it
its own directory and gets more than a single file. :)
Also, I would like the user to get a warning if their GTK+ or GStreamer
version is _newer_ than what is targeted. GTK+ in particular is a
library that has the potential to create compatibility issues, and
it deprecates functions constantly. I want users to know that any kind
of warnings the application is throwing, or any unintended behavior its
displaying, _may_ be the result of non-matching library versions. My
simple Makefile has a decent implementation of this.
Another problem with your package is the following. This program has
directories with content that it relies on. These directories are
docs/, ogg/ and pix/. If a user runs "make", the executable should be
moved into the parent directory for it to find files in those
directories.
Related to this, and equally important, is that "make install" should
take into account the aforementioned directories and that PKGDATADIR in
the source code should (thus) be respected. In the package you sent me,
there are no autoconf/automake related files in, for example, the ogg/
directory. This suggests to me that autoconf/automake ignores this
directory. I can confirm this suspicion by running "make install",
running the program and then selecting "Help..." from the application's
Help menu. It cannot find the docs/README.txt file.
One last thing. Perhaps autoconf/automake requires this, but... The gcc
commands appears to look for header files in directories that I'm
unfamiliar with. Including, but not limited to,
"/usr/include/at-spi-2.0", "/usr/include/dbus-1.0",
"/usr/include/gio-unix-2.0/", "/usr/include/mirclient" and
"/usr/include/harfbuzz". I'm certain that at least some of those
are not used with my Makefile. Maybe configure.ac is adding unnecessary
headers? I don't know enough about the tool to be sure.
I'm aware that I'm asking for a lot. Especially considering that I'm
hoping someone else will take on and finish this task in its entirety.

Hi,
I'm too busy to go into great detail with everything, but atleast it's a start.
I did it to take a break from the programming i was doing, but one thing for
certain is that i'm a gtk (and Qt) hater ;)