[PATCH, M2] introduction of --enable-libm2 in top level directory

[PATCH, M2] introduction of --enable-libm2 in top level directory

[Gaius Mulley]

Below are two patches for configure.ac and Makefile.def which provide
rules for building libm2 and checking gm2.  Tested on trunk and no new
regressions have occurred when building with --enable-languages=all
on x86_64 Debian Wheezy.

More patches will be coming but thought they might be fed in small
groups.

A possible ChangeLog entry might be:

2013-11-19  Gaius Mulley  <gaius.mulley@southwales.ac.uk>

	* configure.ac: Added --enable-libm2.
	* Makefile.def: Added entries for libm2.
	* configure: Regenerated.
	* Makefile.in: Regenerated.

I presume the person committing the patches also regenerates configure
and Makefile.in ?

Hope the patches meet with approval?

regards,
Gaius


--- gcc-trunk-svn/configure.ac	2013-11-14 14:54:10.000000000 +0000
+++ gcc-trunk/configure.ac	2013-11-19 12:05:16.230717741 +0000
@@ -169,7 +169,8 @@
 		${libgcj} \
 		target-libobjc \
 		target-libada \
-		target-libgo"
+		target-libgo \
+		target-libm2"
 
 # these tools are built using the target libraries, and are intended to
 # run only in the target environment
@@ -424,6 +425,12 @@
   noconfigdirs="$noconfigdirs gnattools"
 fi
 
+AC_ARG_ENABLE(libm2,
+[AS_HELP_STRING([--enable-libm2], [build libm2 directory])],
+ENABLE_LIBM2=$enableval,
+ENABLE_LIBM2=yes)
+
+
 AC_ARG_ENABLE(libssp,
 [AS_HELP_STRING([--enable-libssp], [build libssp directory])],
 ENABLE_LIBSSP=$enableval,
--- gcc-trunk-svn/Makefile.def	2013-11-14 14:54:10.000000000 +0000
+++ gcc-trunk/Makefile.def	2013-11-19 12:04:39.686718616 +0000
@@ -152,6 +152,7 @@
 target_modules = { module= libgomp; bootstrap= true; lib_path=.libs; };
 target_modules = { module= libitm; lib_path=.libs; };
 target_modules = { module= libatomic; lib_path=.libs; };
+target_modules = { module= libm2; };
 
 // These are (some of) the make targets to be done in each subdirectory.
 // Not all; these are the ones which don't have special options.
@@ -569,6 +570,8 @@
 languages = { language=obj-c++;	gcc-check-target=check-obj-c++; };
 languages = { language=go;	gcc-check-target=check-go;
 				lib-check-target=check-target-libgo; };
+languages = { language=m2;	gcc-check-target=check-m2;
+				lib-check-target=check-target-libm2; };
 
 // Toplevel bootstrap
 bootstrap_stage = { id=1 ; };

Re: [PATCH, M2] introduction of --enable-libm2 in top level directory

[Joseph S. Myers]

On Tue, 19 Nov 2013, Gaius Mulley wrote:

> Below are two patches for configure.ac and Makefile.def which provide
> rules for building libm2 and checking gm2.  Tested on trunk and no new
> regressions have occurred when building with --enable-languages=all
> on x86_64 Debian Wheezy.

We don't use --enable-<library> options like that.  Instead:

(a) The front end's config-lang.in file sets target_libs, thereby causing 
the library to be disabled if the language is.  Of course this means you 
don't actually add the library before the front end - but these build 
rules are harmless in the absence of the library directory.  (In some 
cases, additional toplevel logic is needed - see how libitm etc. are 
disabled when C++ isn't built - but that shouldn't be relevant here.)

(b) Toplevel configure automatically supports --disable-<subdirectory> 
options to disable building a directory that would otherwise be built by 
default; they don't need adding explicitly.

> I presume the person committing the patches also regenerates configure
> and Makefile.in ?

Yes - and applies the patches to all three relevant repositories (GCC, 
binutils-gdb, src) or asks for help if they don't have access to them all.  
Unfortunately it seems some recent patches haven't gone in src (which is 
still used for newlib).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [PATCH, M2] introduction of --enable-libm2 in top level directory

[Gaius Mulley]

"Joseph S. Myers" <joseph@codesourcery.com> writes:

> On Tue, 19 Nov 2013, Gaius Mulley wrote:
>
> We don't use --enable-<library> options like that.  Instead:
>
> (a) The front end's config-lang.in file sets target_libs, thereby causing 
> the library to be disabled if the language is.  Of course this means you 
> don't actually add the library before the front end - but these build 
> rules are harmless in the absence of the library directory.  (In some 
> cases, additional toplevel logic is needed - see how libitm etc. are 
> disabled when C++ isn't built - but that shouldn't be relevant here.)

ok thanks for directions - I'll resubmit these patches when the front
end is in the tree.

regards,
Gaius