Re: Should Automake still support Java?

[NightStrike]

On Mon, Oct 30, 2017 at 12:09 PM, Mathieu Lirzin  wrote:
> Hello,
>
>Currently Automake supports two ways of compiling Java code.  One is
> with the 'javac' compiler which is deprecated on the Automake side, and
> the other (the recommanded one) which uses GCJ.  Relying on GCJ feels
> outdated since GCJ has been removed from GCC since version 7 and is not
> distributed on recent Debian/Fedora/Ubuntu distributions anymore.
>
>As a consequence, I am considering removing Java support.  Before
> doing that, I would like to consult others, particularly people who may
> still rely on those features.  My questions are the followings:
>
> - Should we remove GCJ support?
> - Should we remove javac support?
> - Should we undeprecate javac support?

Undeprecate, please.

I use automake's java support quite a bit, as I have numerous projects
that are mostly other languages, but that include some java utilities.
It is very nice to manage everything from a single autoconf / automake
setup.  In fact, we picked automake exactly because it supported every
required language.

Please do not remove this support.

> - When should it be done (1.16/1.17/...) ?
>
>If some of you have still access to GCJ, I would be grateful if they
> could help with bug#24895 [1] which can't be adressed otherwise.
>
> Thanks.
>
> [1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24895
>
> --
> Mathieu Lirzin
> GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37
>

Re: Should Automake still support Java?

[Russ Allbery]

Bob Friesenhahn  writes:

> I do not see the point in supporting compiled Java in Automake.  The
> whole point of Java was that it can run in a VM.  GNU support for
> compiled Java seems to have faltered.  Although much useful work was
> done, people just did not start using compiled Java.  The free software
> world seems to have adopted OpenJDK
> (https://en.wikipedia.org/wiki/OpenJDK, http://openjdk.java.net/) and
> this is not even likely supported by Automake.

My feeling matches here, with the addition that the Java world has its own
build systems that are extremely popular and widespread, and Automake
seems to have never caught on.  People with Java projects use Maven
(mostly) or a few other things like ANT to build their projects.  People
who have mixed projects with some C and some Java are more likely to hook
Maven into the build system and delegate the Java build to Maven.

Those build systems are actively developed and kept up to date with
changes in Java, and that's a substantial amount of work.  I think it's
unlikely that Automake's support will be able to keep pace.

I would consider the situation with Java to be very similar to the
situation with Perl, Python, Node, or Ruby: languages that have their own
supported build systems deeply integrated into their ecosystem, where the
best solution for Automake projects is generally to find a way to hook
into that build system and delegate the build steps to the native build
system for that language.

-- 
Russ Allbery (ea...@eyrie.org)  

Re: Should Automake still support Java?

[Bob Friesenhahn]

I do not see the point in supporting compiled Java in Automake.  The 
whole point of Java was that it can run in a VM.  GNU support for 
compiled Java seems to have faltered.  Although much useful work was 
done, people just did not start using compiled Java.  The free 
software world seems to have adopted OpenJDK 
(https://en.wikipedia.org/wiki/OpenJDK, http://openjdk.java.net/) and 
this is not even likely supported by Automake.


As someone who attempted to completely support Automake's Java tests, 
compiling everything from scratch (including the compiler), I can 
attest that it is a major PITA.  I did mostly succeed but there was a 
Java runtime extracted from Eclipse that I never did get working 
correctly given that there was no useful documentation for how to make 
it work.


Please note that I am not a Java developer.

Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

Should Automake still support Java?

[Mathieu Lirzin]

Hello,

   Currently Automake supports two ways of compiling Java code.  One is
with the 'javac' compiler which is deprecated on the Automake side, and
the other (the recommanded one) which uses GCJ.  Relying on GCJ feels
outdated since GCJ has been removed from GCC since version 7 and is not
distributed on recent Debian/Fedora/Ubuntu distributions anymore.

   As a consequence, I am considering removing Java support.  Before
doing that, I would like to consult others, particularly people who may
still rely on those features.  My questions are the followings:

- Should we remove GCJ support?
- Should we remove javac support?
- Should we undeprecate javac support?
- When should it be done (1.16/1.17/...) ?

   If some of you have still access to GCJ, I would be grateful if they
could help with bug#24895 [1] which can't be adressed otherwise.

Thanks.

[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24895

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

bug#28838: Authoritative answer about licensing and copyright of provided scripts and templates

[Mathieu Lirzin]

Hello,

Nick Bowler  writes:

> On 2017-10-14, Joël Krähemann  wrote:
>> I need some authoritative answer about copyright notices to be used
>> for scripts and templates. The files generated by autoscan, autoconf,
>> automake or alike.
>>
>> I need this information in order to proceed with a submission on
>> savannah.gnu.org,
>> https://savannah.gnu.org/task/index.php?14667
>
> Since you posted this to the Automake list I will try to answer the
> Automake part of this question.  Note that I am not a legal expert
> and this is not legal advice (you won't find that on a volunteer
> mailing list).

Since this discussion is not related to an Automake bug, I will close it.

@Joël: If you have other questions regarding the licences of code
generated by automake or aclocal, please ask them on .

Thanks Nick for your explanation.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

bug#28967: How can I resolve this

[Mathieu Lirzin]

Hello,

Sostom M N  writes:

> I am trying to run autoreconf , and this is what i get:
> /usr/share/aclocal/log4c.m4:7: warning: underquoted definition of 
> AM_PATH_LOG4C
> /usr/share/aclocal/log4c.m4:7: run info Automake 'Extending aclocal'
> /usr/share/aclocal/log4c.m4:7: or see 
> http://www.gnu.org/software/automake/manual/automake.html#Extending-aclocal
> /usr/share/aclocal/log4c.m4:7: warning: underquoted definition of 
> AM_PATH_LOG4C
> /usr/share/aclocal/log4c.m4:7: run info Automake 'Extending aclocal'
> /usr/share/aclocal/log4c.m4:7: or see 
> http://www.gnu.org/software/automake/manual/automake.html#Extending-aclocal
> automake: error: global options already processed
> automake: Please contact .
> at /usr/share/automake-1.15/Automake/Channels.pm line 662,  line 105.
> Automake::Channels::msg("automake", "", "global options already processed") 
> called at /usr/share/automake-1.15/Automake/ChannelDefs.pm line 212
> Automake::ChannelDefs::prog_error("global options already processed") called 
> at /usr/share/automake-1.15/Automake/Options.pm line 421
> Automake::Options::process_global_option_list(HASH(0x2f920b0)) called at 
> /usr/bin/automake line 5337
> Automake::scan_autoconf_traces("configure.ac") called at /usr/bin/automake 
> line 5437
> Automake::scan_autoconf_files() called at /usr/bin/automake line 8259
> autoreconf: automake failed with exit status: 29

I would need more context.  Could you give me some instructions to
reproduce this bug?

Thanks.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: Like config.h.in but in Ada

[Mathieu Lirzin]

Victor Porton  writes:

> I want to create file config.ads similar to config.h but with Ada
> syntax instead of C.
>
> I created config.ads.in, added it to configure.ac and got:
>
> package Boiler.Config is
>Data_Dir: constant String := "${prefix}/share";
> end Boiler.Config;
>
> from
>
> package Boiler.Config is
>Data_Dir: constant String := "@datadir@";
> end Boiler.Config;
>
> It is not acceptable because Ada does not understand ${prefix}.
>
> How to make a value into an Ada string (a string delimited by double
> quotes)?
>
> It could be not ideal but acceptable if the code didn't work with paths
> containing double quotes.

I have no experience with Ada however the general fix is to generate
"config.ads" at "make" time so that $prefix variable will be expanded.
in C you can achieve that with CPPFLAGS:

   AM_CPPFLAGS = -DPACKAGE_LOAD_PATH=\"$(moduledir)\"

With other language this has to be done differently, you can use 'sed'
or 'config.status' in your Makefile.  More details are provided in the
Autoconf manual [1].

[1] 
https://www.gnu.org/software/autoconf/manual/autoconf.html#Installation-Directory-Variables

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Like config.h.in but in Ada

[Victor Porton]

I want to create file config.ads similar to config.h but with Ada
syntax instead of C.

I created config.ads.in, added it to configure.ac and got:

package Boiler.Config is
   Data_Dir: constant String := "${prefix}/share";
end Boiler.Config;

from

package Boiler.Config is
   Data_Dir: constant String := "@datadir@";
end Boiler.Config;

It is not acceptable because Ada does not understand ${prefix}.

How to make a value into an Ada string (a string delimited by double
quotes)?

It could be not ideal but acceptable if the code didn't work with paths
containing double quotes.

Re: Dealing with uninstalled data

[Mathieu Lirzin]

Hello,

Victor Porton  writes:

> What is the best way to debug a program which uses some data files,
> while the program is not yet installed?
>
> For example I have data/classes.ttl to be installed into
> /usr/local/share/boiler/classes.ttl
>
> How can I make my program to use this classes.ttl while it is not yet
> installed?
>
> Maybe, I should lookup in current directory? But that's insecure. Maybe
> I should lookup in current directory only in maintainer mode?

I would recommend using environment variables to override the default
installed directories.  To run you program from build directory can then
use a wrapper script that sets those environment variables appropriately
and call your progam this script can be used for running tests too.  As
an example you can see the 'pre-inst-env' script of Automake [1] which
is generated at configure time.

HTH,

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

[1] https://git.savannah.gnu.org/cgit/automake.git/tree/pre-inst-env.in

Dealing with uninstalled data

[Victor Porton]

What is the best way to debug a program which uses some data files,
while the program is not yet installed?

For example I have data/classes.ttl to be installed into
/usr/local/share/boiler/classes.ttl

How can I make my program to use this classes.ttl while it is not yet
installed?

Maybe, I should lookup in current directory? But that's insecure. Maybe
I should lookup in current directory only in maintainer mode?