pre-announce: MELT 0.9.5rc1 plugin for GCC 4.6 & 4.7 pre-release candidate 1 (and help needed on make issues)

pre-announce: MELT 0.9.5rc1 plugin for GCC 4.6 & 4.7 pre-release candidate 1 (and help needed on make issues)

[Basile Starynkevitch]

Hello All,

The pre-release candidate 1 of MELT 0.9.5 is available for testing on
http://gcc-melt.org/melt-0.9.5rc1-plugin-for-gcc-4.6-or-4.7.tar.gz
as a gzipped tar archive of 4473286 bytes and md5sum ae00b9bd31f481e1bbc406711ca4c2f4.
 extracted from MELT branch 185969, march 29th 2012

You could try building it e.g. with 
  make MELTGCC=gcc-4.7 GCCMELT_CC=gcc-4.7 
It seems to be also buildable for GCC 4.6 with
  make MELTGCC=gcc-4.6 GCCMELT_CC=gcc-4.6

(both commands sort of work, with perhaps minor issues very late in the build process;
I'm not very afraid of these)

But I'm trying to code a makefile which would autodetect in GCC 4.7 was compiled in C++
mode (or if the GCC was compiled in C mode, then it is probably a 4.6 or a 4.7
configured in a weird fashion).
 
So far I tried to code in my Makefile the following trick
############################################################################
## the compiler with which melt.so is used
ifndef MELTGCC
MELTGCC = $(or $(CC),gcc)
endif

## gives yes if MELTGCC has been built with C++ or else the empty string
MELTGCC_BUILD_WITH_CXX = $(shell grep -q 'define +ENABLE_BUILD_WITH_CXX +1' \
  `$(MELTGCC) -print-file-name=plugin/include/auto-host.h` && echo yes)

## The compiler and flags used to build the melt.so plugin and to
## compile MELT generated code.  Notice that melt-module.mk use the
## same Make variables.  For a melt plugin to GCC 4.7 or later, that
## could be a C++ compiler! eg
##   make MELTGCC=gcc-4.7 GCCMELT_CC=g++-4.7
## hence we add a test if $(MELTGCC) was built with C++ or with C
ifeq ($(strip $(MELTGCC_BUILD_WITH_CXX)),)
GCCMELT_CC ?= $(or $(CC),gcc) -Wc++-compat
else
GCCMELT_CC ?= $(or $(CXX),g++)
endif

GCCMELT_CFLAGS ?= -g -O -Wall

$(info MELT plugin for MELTGCC= $(MELTGCC) to be compiled with GCCMELT_CC= $(GCCMELT_CC) \
flags $(GCCMELT_CFLAGS) $(if $(MELTGCC_BUILD_WITH_CXX),built with C++ \
$(MELTGCC_BUILD_WITH_CXX)))
### rest of makefile skipped
#############################################################################

but for some reason it does not work. (Maybe a := versus = make variable thing).

Do you have any suggestions about such things?  Assuming a plugin whose source code
should work with both 4.6 & 4.7, how would you autodetect if GCC was compiled in C++ or
in C mode? What am I doing wrong?

Regards.
-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***

Re: [GCC-MELT-386] pre-announce: MELT 0.9.5rc1 plugin for GCC 4.6 & 4.7 pre-release candidate 1 (and help needed on make issues)

[Romain Geissler]

Le 29 mars 2012 à 22:02, Basile Starynkevitch a écrit :

> 
> Hello All,
> 
> The pre-release candidate 1 of MELT 0.9.5 is available for testing on
> http://gcc-melt.org/melt-0.9.5rc1-plugin-for-gcc-4.6-or-4.7.tar.gz
> as a gzipped tar archive of 4473286 bytes and md5sum ae00b9bd31f481e1bbc406711ca4c2f4.
> extracted from MELT branch 185969, march 29th 2012
> 
> You could try building it e.g. with 
>  make MELTGCC=gcc-4.7 GCCMELT_CC=gcc-4.7 
> It seems to be also buildable for GCC 4.6 with
>  make MELTGCC=gcc-4.6 GCCMELT_CC=gcc-4.6
> 
> (both commands sort of work, with perhaps minor issues very late in the build process;
> I'm not very afraid of these)
> 
> But I'm trying to code a makefile which would autodetect in GCC 4.7 was compiled in C++
> mode (or if the GCC was compiled in C mode, then it is probably a 4.6 or a 4.7
> configured in a weird fashion).
> 
> So far I tried to code in my Makefile the following trick
> ############################################################################
> ## the compiler with which melt.so is used
> ifndef MELTGCC
> MELTGCC = $(or $(CC),gcc)
> endif
> 
> ## gives yes if MELTGCC has been built with C++ or else the empty string
> MELTGCC_BUILD_WITH_CXX = $(shell grep -q 'define +ENABLE_BUILD_WITH_CXX +1' \
>  `$(MELTGCC) -print-file-name=plugin/include/auto-host.h` && echo yes)
> 
> ## The compiler and flags used to build the melt.so plugin and to
> ## compile MELT generated code.  Notice that melt-module.mk use the
> ## same Make variables.  For a melt plugin to GCC 4.7 or later, that
> ## could be a C++ compiler! eg
> ##   make MELTGCC=gcc-4.7 GCCMELT_CC=g++-4.7
> ## hence we add a test if $(MELTGCC) was built with C++ or with C
> ifeq ($(strip $(MELTGCC_BUILD_WITH_CXX)),)
> GCCMELT_CC ?= $(or $(CC),gcc) -Wc++-compat
> else
> GCCMELT_CC ?= $(or $(CXX),g++)
> endif
> 
> GCCMELT_CFLAGS ?= -g -O -Wall
> 
> $(info MELT plugin for MELTGCC= $(MELTGCC) to be compiled with GCCMELT_CC= $(GCCMELT_CC) \
> flags $(GCCMELT_CFLAGS) $(if $(MELTGCC_BUILD_WITH_CXX),built with C++ \
> $(MELTGCC_BUILD_WITH_CXX)))
> ### rest of makefile skipped
> #############################################################################
> 
> but for some reason it does not work. (Maybe a := versus = make variable thing).
> 
> Do you have any suggestions about such things?  Assuming a plugin whose source code
> should work with both 4.6 & 4.7, how would you autodetect if GCC was compiled in C++ or
> in C mode? What am I doing wrong?
> 
> Regards.
> -- 
> Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
> email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
> 8, rue de la Faiencerie, 92340 Bourg La Reine, France
> *** opinions {are only mine, sont seulement les miennes} ***
> 
> -- 
> Message from the http://groups.google.com/group/gcc-melt group.
> About GCC MELT http://gcc-melt.org/ a high level domain specific language to code extensions to the Gnu Compiler Collection

Hi, 

You almost got it. You simply need to backslash escape the '+' operator in your regexp.
Also, it would be welcome to allow any blank chars to separate words, not any the space char
(\t for example). Thus, i changed space ' ' by [[:space:]] (tested with GNU grep).

MELTGCC_BUILD_WITH_CXX = $(shell grep -q 'define[[:space:]]\+ENABLE_BUILD_WITH_CXX[[:space:]]\+1' \
  `$(MELTGCC) -print-file-name=plugin/include/auto-host.h` && echo yes)

Anyway, as i already told you, you don't look for gengtype and gtype.state at the right place.

Romain Geissler

Re: [GCC-MELT-387] pre-announce: MELT 0.9.5rc1 plugin for GCC 4.6 & 4.7 pre-release candidate 1 (and help needed on make issues)

[Basile Starynkevitch]

On Thu, 29 Mar 2012 22:45:27 +0200
Romain Geissler <romain.geissler@gmail.com> wrote:

> MELTGCC_BUILD_WITH_CXX = $(shell grep -q 'define[[:space:]]\+ENABLE_BUILD_WITH_CXX[[:space:]]\+1' \
>   `$(MELTGCC) -print-file-name=plugin/include/auto-host.h` && echo yes)
> 

Thanks; I applied that patch with


2012-03-29  Romain Geissler  <romain.geissler@gmail.com>
	* MELT-Plugin-Makefile (MELTGCC_BUILD_WITH_CXX): Better grep.


(I will test it tomorrow)
Cheers.
-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***

Re: [GCC-MELT-387] pre-announce: MELT 0.9.5rc1 plugin for GCC 4.6 & 4.7 pre-release candidate 1 (and help needed on make issues)

[Romain Geissler]

Le 29 mars 2012 à 23:03, Basile Starynkevitch a écrit :

> On Thu, 29 Mar 2012 22:45:27 +0200
> Romain Geissler <romain.geissler@gmail.com> wrote:
> 
>> MELTGCC_BUILD_WITH_CXX = $(shell grep -q 'define[[:space:]]\+ENABLE_BUILD_WITH_CXX[[:space:]]\+1' \
>>  `$(MELTGCC) -print-file-name=plugin/include/auto-host.h` && echo yes)
>> 
> 
> Thanks; I applied that patch with
> 
> 
> 2012-03-29  Romain Geissler  <romain.geissler@gmail.com>
> 	* MELT-Plugin-Makefile (MELTGCC_BUILD_WITH_CXX): Better grep.
> 
> 
> (I will test it tomorrow)
> Cheers.

You've made a typo will copy/pasting part of the line. Look at the dollar $ char
near '=$ (shell)', the space is misplaced. It should be '= $(shell'.

Romain Geissler

Re: [GCC-MELT-387] pre-announce: MELT 0.9.5rc1 plugin for GCC 4.6 & 4.7 pre-release candidate 1 (and help needed on make issues)

[Basile Starynkevitch]

On Thu, 29 Mar 2012 23:29:40 +0200
Romain Geissler <romain.geissler@gmail.com> wrote:
> 
> You've made a typo will copy/pasting part of the line. Look at the dollar $ char
> near '=$ (shell)', the space is misplaced. It should be '= $(shell'.


Thanks! Corrected.


-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***

MELT 0.9.5rc1 etc...

[Basile Starynkevitch]

Hello

If you want to help me on the makefile issues for the next MELT plugin
release 0.9.5, please extract the MELT plugin from the svn repository, since
I am making small changes (which still don't work) since 0.9.5rc1

The procedure to extract the MELT plugin from the MELT brannch is:

Retrieve the MELT branch if you don't have it

   svn co svn://gcc.gnu.org/svn/gcc/branches/melt-branch gcc-melt

Go into it

   cd gcc-melt

Run the update to be sure to have the latest SVN & to gernerate the REVISION
etc files

   ./contrib/gcc_update

Run the following script to get the MELT plugin tarball

   ./contrib/make-melt-source-tar.sh $PWD /tmp/meltplugin

You now should have a /tmp/meltplugin.tar.gz which is the MELT plugin
tarball corresponding to your state of the MELT branch

Regards.
-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

Re: [GCC-MELT-391] MELT 0.9.5rc1 etc...

[Romain Geissler]

[-- Attachment #1: Type: text/plain, Size: 1951 bytes --]

Le 30 mars 2012 à 11:40, Basile Starynkevitch a écrit :

> Hello
> 
> If you want to help me on the makefile issues for the next MELT plugin
> release 0.9.5, please extract the MELT plugin from the svn repository, since
> I am making small changes (which still don't work) since 0.9.5rc1
> 
> The procedure to extract the MELT plugin from the MELT brannch is:
> 
> Retrieve the MELT branch if you don't have it
> 
>   svn co svn://gcc.gnu.org/svn/gcc/branches/melt-branch gcc-melt
> 
> Go into it
> 
>   cd gcc-melt
> 
> Run the update to be sure to have the latest SVN & to gernerate the REVISION
> etc files
> 
>   ./contrib/gcc_update
> 
> Run the following script to get the MELT plugin tarball
> 
>   ./contrib/make-melt-source-tar.sh $PWD /tmp/meltplugin
> 
> You now should have a /tmp/meltplugin.tar.gz which is the MELT plugin
> tarball corresponding to your state of the MELT branch
> 
> Regards.
> -- 
> Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
> email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
> 8, rue de la Faiencerie, 92340 Bourg La Reine, France
> *** opinions {are only mines, sont seulement les miennes} ***
> 

Hi,

I tried to build the latest melt-branch (not the generated tarball) on a mac.
Here is the few change required to allow the build (note that it builds but as your
cc/cxx detection still fails, the generated melt-runtime.o and *.so files can't be
loaded with gcc build with cxx).

I removed the test of _POSIX_C_SOURCE in melt-runtime.c because this
makes no sense to test the availability of the poll function that way : just use
the function, the compiler will find it out by itself if it is really defined. Moreover,
this kind of test should be in a configure file, not in a source file. On a mac,
_POSIX_C_SOURCE is not defined by default, and defining it lead to errors
while building other parts of GCC.

Romain Geissler


[-- Attachment #2: melt-mac-build.Changelog --]
[-- Type: application/octet-stream, Size: 216 bytes --]

2012-03-31  Romain Geissler  <romain.geissler@gmail.com>

	* melt-build.tpl: Use AWK instead of GAWK.
	* melt-module.mk: Likewise.
	* melt-build.mk: Regenerate.
	* melt-runtime.c: Do not check _POSIX_C_SOURCE value.

[-- Attachment #3: melt-mac-build.diff --]
[-- Type: application/octet-stream, Size: 14717 bytes --]

diff --git gcc/melt-build.mk gcc/melt-build.mk
index 3aa9011..4218b1d 100644
--- gcc/melt-build.mk
+++ gcc/melt-build.mk
@@ -3,7 +3,7 @@
 #@#@# 
 #@#@# DO NOT EDIT THIS FILE   (melt-build.mk)
 #@#@# 
-#@#@# It has been AutoGen-ed  March 30, 2012 at 10:56:40 AM by AutoGen 5.12
+#@#@# It has been AutoGen-ed  March 31, 2012 at 01:19:19 AM by AutoGen 5.11.1
 #@#@# From the definitions    melt-build.def
 #@#@# and the template file   melt-build.tpl
 ##@@ melt-build.mk is generated from melt-build.tpl by 'autogen melt-build.def'
@@ -21,7 +21,7 @@
 # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 # GNU General Public License for more details.
 # 
-#@ from melt-build.tpl line 22 generated by Autogen 5.12 using melt-build.def
+#@ from melt-build.tpl line 22 generated by Autogen 5.11.1 using melt-build.def
 ## See http://stackoverflow.com/q/8727896/841108
 ## and http://lists.gnu.org/archive/html/help-make/2012-01/msg00017.html
 ## and http://gcc.gnu.org/ml/gcc/2012-01/msg00089.html
@@ -131,8 +131,8 @@ endif
 ## LN_S might not be defined, e.g. in MELT-Plugin-Makefile from melt-build.tpl line 71
 LN_S ?= ln -sv
 
-## GAWK is needed, the GNU awk from melt-build.tpl line 74
-GAWK ?= gawk
+## AWK is needed from melt-build.tpl line 74
+AWK ?= awk
 
 ## the md5sum utility is needed  from melt-build.tpl line 77
 MD5SUM ?= md5sum
@@ -241,7 +241,7 @@ MELT_ZERO_GENERATED_FIRST_BASE= \
                   $(basename $(notdir $(MELT_GENERATED_FIRST_C_FILES)))
 # for stage 0 files, we don't compute the checksum, we extract what was deposited from melt-build.tpl line 171
 ## avoid spaces in MELT_GENERATED_FIRST_CUMULMD5 below from melt-build.tpl line 172
-MELT_ZERO_GENERATED_FIRST_CUMULMD5:=$(shell $(GAWK) -F\" '/extern/{next} /melt_cumulated_hexmd5/{print $$2}' $(melt_make_source_dir)/generated/warmelt-first+meltdesc.c)
+MELT_ZERO_GENERATED_FIRST_CUMULMD5:=$(shell $(AWK) -F\" '/extern/{next} /melt_cumulated_hexmd5/{print $$2}' $(melt_make_source_dir)/generated/warmelt-first+meltdesc.c)
 
 #@ The C files of the stage 0 are deposited from melt-build.tpl line 164
 MELT_ZERO_GENERATED_BASE_C_FILES= \
@@ -252,7 +252,7 @@ MELT_ZERO_GENERATED_BASE_BASE= \
                   $(basename $(notdir $(MELT_GENERATED_BASE_C_FILES)))
 # for stage 0 files, we don't compute the checksum, we extract what was deposited from melt-build.tpl line 171
 ## avoid spaces in MELT_GENERATED_BASE_CUMULMD5 below from melt-build.tpl line 172
-MELT_ZERO_GENERATED_BASE_CUMULMD5:=$(shell $(GAWK) -F\" '/extern/{next} /melt_cumulated_hexmd5/{print $$2}' $(melt_make_source_dir)/generated/warmelt-base+meltdesc.c)
+MELT_ZERO_GENERATED_BASE_CUMULMD5:=$(shell $(AWK) -F\" '/extern/{next} /melt_cumulated_hexmd5/{print $$2}' $(melt_make_source_dir)/generated/warmelt-base+meltdesc.c)
 
 #@ The C files of the stage 0 are deposited from melt-build.tpl line 164
 MELT_ZERO_GENERATED_DEBUG_C_FILES= \
@@ -263,7 +263,7 @@ MELT_ZERO_GENERATED_DEBUG_BASE= \
                   $(basename $(notdir $(MELT_GENERATED_DEBUG_C_FILES)))
 # for stage 0 files, we don't compute the checksum, we extract what was deposited from melt-build.tpl line 171
 ## avoid spaces in MELT_GENERATED_DEBUG_CUMULMD5 below from melt-build.tpl line 172
-MELT_ZERO_GENERATED_DEBUG_CUMULMD5:=$(shell $(GAWK) -F\" '/extern/{next} /melt_cumulated_hexmd5/{print $$2}' $(melt_make_source_dir)/generated/warmelt-debug+meltdesc.c)
+MELT_ZERO_GENERATED_DEBUG_CUMULMD5:=$(shell $(AWK) -F\" '/extern/{next} /melt_cumulated_hexmd5/{print $$2}' $(melt_make_source_dir)/generated/warmelt-debug+meltdesc.c)
 
 #@ The C files of the stage 0 are deposited from melt-build.tpl line 164
 MELT_ZERO_GENERATED_MACRO_C_FILES= \
@@ -274,7 +274,7 @@ MELT_ZERO_GENERATED_MACRO_BASE= \
                   $(basename $(notdir $(MELT_GENERATED_MACRO_C_FILES)))
 # for stage 0 files, we don't compute the checksum, we extract what was deposited from melt-build.tpl line 171
 ## avoid spaces in MELT_GENERATED_MACRO_CUMULMD5 below from melt-build.tpl line 172
-MELT_ZERO_GENERATED_MACRO_CUMULMD5:=$(shell $(GAWK) -F\" '/extern/{next} /melt_cumulated_hexmd5/{print $$2}' $(melt_make_source_dir)/generated/warmelt-macro+meltdesc.c)
+MELT_ZERO_GENERATED_MACRO_CUMULMD5:=$(shell $(AWK) -F\" '/extern/{next} /melt_cumulated_hexmd5/{print $$2}' $(melt_make_source_dir)/generated/warmelt-macro+meltdesc.c)
 
 #@ The C files of the stage 0 are deposited from melt-build.tpl line 164
 MELT_ZERO_GENERATED_NORMAL_C_FILES= \
@@ -285,7 +285,7 @@ MELT_ZERO_GENERATED_NORMAL_BASE= \
                   $(basename $(notdir $(MELT_GENERATED_NORMAL_C_FILES)))
 # for stage 0 files, we don't compute the checksum, we extract what was deposited from melt-build.tpl line 171
 ## avoid spaces in MELT_GENERATED_NORMAL_CUMULMD5 below from melt-build.tpl line 172
-MELT_ZERO_GENERATED_NORMAL_CUMULMD5:=$(shell $(GAWK) -F\" '/extern/{next} /melt_cumulated_hexmd5/{print $$2}' $(melt_make_source_dir)/generated/warmelt-normal+meltdesc.c)
+MELT_ZERO_GENERATED_NORMAL_CUMULMD5:=$(shell $(AWK) -F\" '/extern/{next} /melt_cumulated_hexmd5/{print $$2}' $(melt_make_source_dir)/generated/warmelt-normal+meltdesc.c)
 
 #@ The C files of the stage 0 are deposited from melt-build.tpl line 164
 MELT_ZERO_GENERATED_NORMATCH_C_FILES= \
@@ -296,7 +296,7 @@ MELT_ZERO_GENERATED_NORMATCH_BASE= \
                   $(basename $(notdir $(MELT_GENERATED_NORMATCH_C_FILES)))
 # for stage 0 files, we don't compute the checksum, we extract what was deposited from melt-build.tpl line 171
 ## avoid spaces in MELT_GENERATED_NORMATCH_CUMULMD5 below from melt-build.tpl line 172
-MELT_ZERO_GENERATED_NORMATCH_CUMULMD5:=$(shell $(GAWK) -F\" '/extern/{next} /melt_cumulated_hexmd5/{print $$2}' $(melt_make_source_dir)/generated/warmelt-normatch+meltdesc.c)
+MELT_ZERO_GENERATED_NORMATCH_CUMULMD5:=$(shell $(AWK) -F\" '/extern/{next} /melt_cumulated_hexmd5/{print $$2}' $(melt_make_source_dir)/generated/warmelt-normatch+meltdesc.c)
 
 #@ The C files of the stage 0 are deposited from melt-build.tpl line 164
 MELT_ZERO_GENERATED_GENOBJ_C_FILES= \
@@ -307,7 +307,7 @@ MELT_ZERO_GENERATED_GENOBJ_BASE= \
                   $(basename $(notdir $(MELT_GENERATED_GENOBJ_C_FILES)))
 # for stage 0 files, we don't compute the checksum, we extract what was deposited from melt-build.tpl line 171
 ## avoid spaces in MELT_GENERATED_GENOBJ_CUMULMD5 below from melt-build.tpl line 172
-MELT_ZERO_GENERATED_GENOBJ_CUMULMD5:=$(shell $(GAWK) -F\" '/extern/{next} /melt_cumulated_hexmd5/{print $$2}' $(melt_make_source_dir)/generated/warmelt-genobj+meltdesc.c)
+MELT_ZERO_GENERATED_GENOBJ_CUMULMD5:=$(shell $(AWK) -F\" '/extern/{next} /melt_cumulated_hexmd5/{print $$2}' $(melt_make_source_dir)/generated/warmelt-genobj+meltdesc.c)
 
 #@ The C files of the stage 0 are deposited from melt-build.tpl line 164
 MELT_ZERO_GENERATED_OUTOBJ_C_FILES= \
@@ -318,7 +318,7 @@ MELT_ZERO_GENERATED_OUTOBJ_BASE= \
                   $(basename $(notdir $(MELT_GENERATED_OUTOBJ_C_FILES)))
 # for stage 0 files, we don't compute the checksum, we extract what was deposited from melt-build.tpl line 171
 ## avoid spaces in MELT_GENERATED_OUTOBJ_CUMULMD5 below from melt-build.tpl line 172
-MELT_ZERO_GENERATED_OUTOBJ_CUMULMD5:=$(shell $(GAWK) -F\" '/extern/{next} /melt_cumulated_hexmd5/{print $$2}' $(melt_make_source_dir)/generated/warmelt-outobj+meltdesc.c)
+MELT_ZERO_GENERATED_OUTOBJ_CUMULMD5:=$(shell $(AWK) -F\" '/extern/{next} /melt_cumulated_hexmd5/{print $$2}' $(melt_make_source_dir)/generated/warmelt-outobj+meltdesc.c)
 
 #@ The C files of the stage 0 are deposited from melt-build.tpl line 164
 MELT_ZERO_GENERATED_MODES_C_FILES= \
@@ -329,7 +329,7 @@ MELT_ZERO_GENERATED_MODES_BASE= \
                   $(basename $(notdir $(MELT_GENERATED_MODES_C_FILES)))
 # for stage 0 files, we don't compute the checksum, we extract what was deposited from melt-build.tpl line 171
 ## avoid spaces in MELT_GENERATED_MODES_CUMULMD5 below from melt-build.tpl line 172
-MELT_ZERO_GENERATED_MODES_CUMULMD5:=$(shell $(GAWK) -F\" '/extern/{next} /melt_cumulated_hexmd5/{print $$2}' $(melt_make_source_dir)/generated/warmelt-modes+meltdesc.c)
+MELT_ZERO_GENERATED_MODES_CUMULMD5:=$(shell $(AWK) -F\" '/extern/{next} /melt_cumulated_hexmd5/{print $$2}' $(melt_make_source_dir)/generated/warmelt-modes+meltdesc.c)
 
 
 #@ the required work directory from melt-build.tpl line 176
diff --git gcc/melt-build.tpl gcc/melt-build.tpl
index ebdb4b5..c55ae24 100644
--- gcc/melt-build.tpl
+++ gcc/melt-build.tpl
@@ -71,8 +71,8 @@ endif
 ## LN_S might not be defined, e.g. in MELT-Plugin-Makefile [+ (. (tpl-file-line))+]
 LN_S ?= ln -sv
 
-## GAWK is needed, the GNU awk [+ (. (tpl-file-line))+]
-GAWK ?= gawk
+## AWK is needed [+ (. (tpl-file-line))+]
+AWK ?= awk
 
 ## the md5sum utility is needed  [+ (. (tpl-file-line))+]
 MD5SUM ?= md5sum
@@ -170,7 +170,7 @@ MELT_ZERO_GENERATED_[+mkvarsuf+]_BASE= \
                   $(basename $(notdir $(MELT_GENERATED_[+mkvarsuf+]_C_FILES)))
 # for stage 0 files, we don't compute the checksum, we extract what was deposited [+ (. (tpl-file-line))+]
 ## avoid spaces in MELT_GENERATED_[+mkvarsuf+]_CUMULMD5 below [+ (. (tpl-file-line))+]
-MELT_ZERO_GENERATED_[+mkvarsuf+]_CUMULMD5:=$(shell $(GAWK) -F\" '/extern/{next} /melt_cumulated_hexmd5/{print $$2}' $(melt_make_source_dir)/generated/[+base+]+meltdesc.c)
+MELT_ZERO_GENERATED_[+mkvarsuf+]_CUMULMD5:=$(shell $(AWK) -F\" '/extern/{next} /melt_cumulated_hexmd5/{print $$2}' $(melt_make_source_dir)/generated/[+base+]+meltdesc.c)
 [+ENDFOR melt_translator_file+]
 
 #@ the required work directory [+ (. (tpl-file-line))+]
diff --git gcc/melt-module.mk gcc/melt-module.mk
index fedb20a..78dae26 100644
--- gcc/melt-module.mk
+++ gcc/melt-module.mk
@@ -72,10 +72,8 @@ ifeq ($(findstring $(GCCMELT_MODULE_FLAVOR),optimized quicklybuilt debugnoline d
 $(error invalid GCCMELT_MODULE_FLAVOR $(GCCMELT_MODULE_FLAVOR))
 endif
 
-### GNU awk is required
-ifndef GAWK
-GAWK=gawk
-endif
+### awk is required
+AWK?=awk
 
 ## The md5sum command is required
 MD5SUM ?= md5sum
@@ -90,6 +88,12 @@ GCCMELT_CC ?= $(firstword $(GCC) gcc)
 GCCMELT_BASE=$(notdir $(basename $(GCCMELT_MODULE_SOURCEBASE)))
 GCCMELT_SOURCEDIR=$(dir $(GCCMELT_MODULE_SOURCEBASE))
 
+ifeq ($(shell uname),Darwin)
+SHARED_LIBRARY_FLAGS=-bundle -undefined dynamic_lookup
+else
+SHARED_LIBRARY_FLAGS=-shared
+endif
+
 ## these flags should only affect the quality of the generated
 ## binaries. No preprocessor flags please here!
 GCCMELT_OPTIMIZED_FLAGS ?= -O1
@@ -105,16 +109,16 @@ $(error Did not found MELT primary file  $(GCCMELT_MODULE_SOURCEBASE).c)
 endif
 
 ## the md5 checksum of the primary file
-GCCMELT_PRIMARYMD5:= $(shell $(MD5SUM) $(GCCMELT_PRIMARY) | $(GAWK) '{print $$1}')
+GCCMELT_PRIMARYMD5:= $(shell $(MD5SUM) $(GCCMELT_PRIMARY) | $(AWK) '{print $$1}')
 
 ## the secondary C files, in order
 GCCMELT_SECONDARIES= $(sort $(wildcard $(GCCMELT_MODULE_SOURCEBASE)+[09]*.c))
 ## the corresponding checksums
 GCCMELT_SECONDARIES_MD5:= $(if $(GCCMELT_SECONDARIES), \
-		$(shell  $(MD5SUM) $(GCCMELT_SECONDARIES)  | $(GAWK) '{print $$1}'))
+		$(shell  $(MD5SUM) $(GCCMELT_SECONDARIES)  | $(AWK) '{print $$1}'))
 
 ## the cumulated checksum
-GCCMELT_CUMULATED_MD5 ?= $(shell cat $(GCCMELT_PRIMARY)  $(GCCMELT_SECONDARIES) | $(MD5SUM)  | $(GAWK) '{print $$1}')
+GCCMELT_CUMULATED_MD5 ?= $(shell cat $(GCCMELT_PRIMARY)  $(GCCMELT_SECONDARIES) | $(MD5SUM)  | $(AWK) '{print $$1}')
 
 ## the primary object basename
 GCCMELT_PRIMARY_OBJ:= $(basename $(notdir $(GCCMELT_PRIMARY))).$(GCCMELT_PRIMARYMD5)
@@ -161,7 +165,7 @@ $(GCCMELT_MODULE_WORKSPACE)/$(GCCMELT_BASE).$(GCCMELT_CUMULATED_MD5).optimized.s
 	   GCCMELT_MODULE_WORKSPACE=$(GCCMELT_MODULE_WORKSPACE) \
 	   GCCMELT_MODULE_FLAVOR=$(GCCMELT_MODULE_FLAVOR) \
 	   GCCMELT_CUMULATED_MD5=$(GCCMELT_CUMULATED_MD5)
-	$(GCCMELT_CC) $(GCCMELT_OPTIMIZED_FLAGS) $(GCCMELT_CFLAGS) -fPIC -shared -o $@  $^ $(GCCMELT_MODULE_EXTRALIBES)
+	$(GCCMELT_CC) $(GCCMELT_OPTIMIZED_FLAGS) $(GCCMELT_CFLAGS) -fPIC $(SHARED_LIBRARY_FLAGS) -o $@  $^ $(GCCMELT_MODULE_EXTRALIBES)
 
 $(GCCMELT_MODULE_WORKSPACE)/$(GCCMELT_BASE).$(GCCMELT_CUMULATED_MD5).dynamic.so: \
   $(GCCMELT_MODULE_WORKSPACE)/$(GCCMELT_PRIMARY_OBJ).dynamic.pic.o \
@@ -173,7 +177,7 @@ $(GCCMELT_MODULE_WORKSPACE)/$(GCCMELT_BASE).$(GCCMELT_CUMULATED_MD5).dynamic.so:
 	   GCCMELT_MODULE_WORKSPACE=$(GCCMELT_MODULE_WORKSPACE) \
 	   GCCMELT_MODULE_FLAVOR=$(GCCMELT_MODULE_FLAVOR) \
 	   GCCMELT_CUMULATED_MD5=$(GCCMELT_CUMULATED_MD5)
-	$(GCCMELT_CC) $(GCCMELT_DYNAMIC_FLAGS) $(GCCMELT_CFLAGS) -fPIC -shared -o $@  $^  $(GCCMELT_MODULE_EXTRALIBES)
+	$(GCCMELT_CC) $(GCCMELT_DYNAMIC_FLAGS) $(GCCMELT_CFLAGS) -fPIC $(SHARED_LIBRARY_FLAGS) -o $@  $^  $(GCCMELT_MODULE_EXTRALIBES)
 
 $(GCCMELT_MODULE_WORKSPACE)/$(GCCMELT_BASE).$(GCCMELT_CUMULATED_MD5).quicklybuilt.so: \
   $(GCCMELT_MODULE_WORKSPACE)/$(GCCMELT_PRIMARY_OBJ).quicklybuilt.pic.o \
@@ -185,7 +189,7 @@ $(GCCMELT_MODULE_WORKSPACE)/$(GCCMELT_BASE).$(GCCMELT_CUMULATED_MD5).quicklybuil
 	   GCCMELT_MODULE_WORKSPACE=$(GCCMELT_MODULE_WORKSPACE) \
 	   GCCMELT_MODULE_FLAVOR=$(GCCMELT_MODULE_FLAVOR) \
 	   GCCMELT_CUMULATED_MD5=$(GCCMELT_CUMULATED_MD5)
-	$(GCCMELT_CC) $(GCCMELT_QUICKLYBUILT_FLAGS) $(GCCMELT_CFLAGS) -fPIC -shared -o $@ $^  $(GCCMELT_MODULE_EXTRALIBES)
+	$(GCCMELT_CC) $(GCCMELT_QUICKLYBUILT_FLAGS) $(GCCMELT_CFLAGS) -fPIC $(SHARED_LIBRARY_FLAGS) -o $@ $^  $(GCCMELT_MODULE_EXTRALIBES)
 
 
 $(GCCMELT_MODULE_WORKSPACE)/$(GCCMELT_BASE).$(GCCMELT_CUMULATED_MD5).debugnoline.so: \
@@ -198,7 +202,7 @@ $(GCCMELT_MODULE_WORKSPACE)/$(GCCMELT_BASE).$(GCCMELT_CUMULATED_MD5).debugnoline
 	   GCCMELT_MODULE_WORKSPACE=$(GCCMELT_MODULE_WORKSPACE) \
 	   GCCMELT_MODULE_FLAVOR=$(GCCMELT_MODULE_FLAVOR) \
 	   GCCMELT_CUMULATED_MD5=$(GCCMELT_CUMULATED_MD5)
-	$(GCCMELT_CC) $(GCCMELT_DEBUGNOLINE_FLAGS) $(GCCMELT_CFLAGS) -fPIC -shared -o $@  $^  $(GCCMELT_MODULE_EXTRALIBES)
+	$(GCCMELT_CC) $(GCCMELT_DEBUGNOLINE_FLAGS) $(GCCMELT_CFLAGS) -fPIC $(SHARED_LIBRARY_FLAGS) -o $@  $^  $(GCCMELT_MODULE_EXTRALIBES)
 
 
 $(GCCMELT_MODULE_BINARYBASE).$(GCCMELT_MODULE_FLAVOR).so: $(GCCMELT_MODULE_WORKSPACE)/$(GCCMELT_BASE).$(GCCMELT_CUMULATED_MD5).$(GCCMELT_MODULE_FLAVOR).so
diff --git gcc/melt-runtime.c gcc/melt-runtime.c
index 87168cb..b81b454 100644
--- gcc/melt-runtime.c
+++ gcc/melt-runtime.c
@@ -13306,9 +13306,6 @@ meltgc_poll_inputs (melt_ptr_t inbuck_p, int delayms)
 #define seqv      meltfram__.mcfr_varptr[3]
 #define closv     meltfram__.mcfr_varptr[4]
   MELT_LOCATION_HERE("meltgc_poll_inputs");
-#if _POSIX_C_SOURCE < 200112L
-#error meltgc_poll_inputs need a Posix 2001 system with poll
-#endif /* _POSIX_C_SOURCE < 200112L */
   inbuckv = inbuck_p;
   if (melt_magic_discr ((melt_ptr_t) inbuckv) != MELTOBMAG_BUCKETLONGS)
     goto end;

[-- Attachment #4: Type: text/plain, Size: 3 bytes --]

Re: [GCC-MELT-391] MELT 0.9.5rc1 etc...

[Basile Starynkevitch]

On Sat, 31 Mar 2012 02:22:43 +0200
Romain Geissler <romain.geissler@gmail.com> wrote:

> 
> I tried to build the latest melt-branch (not the generated tarball) on a mac.
> Here is the few change required to allow the build (note that it builds but as your
> cc/cxx detection still fails, the generated melt-runtime.o and *.so files can't be
> loaded with gcc build with cxx).

Thanks! But please patch melt-build.tpl, not melt-build.mk which is autogen generated.
> 
> I removed the test of _POSIX_C_SOURCE in melt-runtime.c because this
> makes no sense to test the availability of the poll function that way : just use
> the function, the compiler will find it out by itself if it is really defined. Moreover,
> this kind of test should be in a configure file, not in a source file. On a mac,
> _POSIX_C_SOURCE is not defined by default, and defining it lead to errors
> while building other parts of GCC.

Do you have any ideas on how to make autoconf things for the MELT plugin?

Also, I was believing MacOSX needs *dylib files not *so one ?

Thanks, cheers


-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***

Re: [GCC-MELT-391] MELT 0.9.5rc1 etc...

[Romain Geissler]

Le 31 mars 2012 à 09:07, Basile Starynkevitch a écrit :

> On Sat, 31 Mar 2012 02:22:43 +0200
> Romain Geissler <romain.geissler@gmail.com> wrote:
> 
>> 
>> I tried to build the latest melt-branch (not the generated tarball) on a mac.
>> Here is the few change required to allow the build (note that it builds but as your
>> cc/cxx detection still fails, the generated melt-runtime.o and *.so files can't be
>> loaded with gcc build with cxx).
> 
> Thanks! But please patch melt-build.tpl, not melt-build.mk which is autogen generated.

Well I know it's autogenerated, that's why i wrote 'Regenerate.' in the Changelog.
In such cases, i should not include the regenerated file to the patch ? Is it the
maintainer role to run autogen on every patch that affects *.tpl ?

>> 
>> I removed the test of _POSIX_C_SOURCE in melt-runtime.c because this
>> makes no sense to test the availability of the poll function that way : just use
>> the function, the compiler will find it out by itself if it is really defined. Moreover,
>> this kind of test should be in a configure file, not in a source file. On a mac,
>> _POSIX_C_SOURCE is not defined by default, and defining it lead to errors
>> while building other parts of GCC.
> 
> Do you have any ideas on how to make autoconf things for the MELT plugin?

Well I currently don't know, although i already patched the GCC configuration
scripts. It's like all, just need to learn.

> 
> Also, I was believing MacOSX needs *dylib files not *so one ?

Yes dynamic libraries are named *.dylib on a mac because the dynamic
linker dyld looks for *.dylib files, and not *.so files.

OSX makes a difference between a dynamic library you can link (*.dylib)
width dyld and binaries you dynamically load on your own with dlopen
(*.bundle). So on a mac, your melt plugins should have the .bundle
extension.

But as the .so extension is hardcoded almost everywhere, i preferred keeping
the .so extension, like many other projects do (on my computer, i can see
that apache, php, valgrind, ImageMagick, python, gtk and many others just
do the same)

Romain Geissler

Re: [GCC-MELT-391] MELT 0.9.5rc1 etc...

[Basile Starynkevitch]

On Sat, 31 Mar 2012 10:52:09 +0200
Romain Geissler <romain.geissler@gmail.com> wrote:

> 
> Le 31 mars 2012 à 09:07, Basile Starynkevitch a écrit :
> 
> > On Sat, 31 Mar 2012 02:22:43 +0200
> > Romain Geissler <romain.geissler@gmail.com> wrote:
> > 
> >> 
> >> I tried to build the latest melt-branch (not the generated tarball) on a mac.
> >> Here is the few change required to allow the build (note that it builds but as your
> >> cc/cxx detection still fails, the generated melt-runtime.o and *.so files can't be
> >> loaded with gcc build with cxx).
> > 
> > Thanks! But please patch melt-build.tpl, not melt-build.mk which is autogen generated.


Sorry, my apologies, I didn't saw the patch to melt-build.tpl later in your diff.

> Well I know it's autogenerated, that's why i wrote 'Regenerate.' in the Changelog.
> In such cases, i should not include the regenerated file to the patch ? Is it the
> maintainer role to run autogen on every patch that affects *.tpl ?

the melt-build.mk is generated from melt-build.tpl & melt-build.def; after running
autogen which generates melt-build.mk in the source tree, we can svn commit.

This is exactly the same practice as for configure generated from configure.ac in the
trunk. Contributors patch configure.ac, regenerate configure (both in the source tree)
and then svn commit (after patch approval) both.

For MELT, the translator itself (files gcc/melt/generated/{warmelt*.[ch]) and some parts
of the runtime (files gcc/melt/generated/meltrunsup*.[ch]) are also generated and svn
commit-ed in the trunk. FYI I use make upgrade-warmelt to regenerate them.

I am surprised of your patch which indeed contains gcc/melt-build.tpl:

-## GAWK is needed, the GNU awk [+ (. (tpl-file-line))+]
-GAWK ?= gawk
+## AWK is needed [+ (. (tpl-file-line))+]
+AWK ?= awk
 

I really need GNU awk (and I may depend upon GNU extensions of awk). AFAIK, GCC also
requires *GNU* awk specifically (and not some other awk). Why the above patch? If GNU awk
is called awk on MacOS (like it is on some Linux distributions) just call it still GAWK in
makefile things! I'm pretty sure to not be the only one with this convention, that GAWK in
Makefile meen that GNU extensions of awk is necessary.


A more general question is the status of plugins on MacOSX. I thought that GCC plugins in
general only work for ELF shared object systems with dlopen. It seems that gcc/plugin.c
is hardwiring the ".so" suffix in function add_new_plugin. Can an unpatched GCC 4.7 (FSF
distributed) be built on MacOSX with plugins enabled and working? Does dlopen as
specified by Posix: http://pubs.opengroup.org/onlinepubs/009695399/functions/dlopen.html
etc work on MacOSX (in particular when file is NULL and mode contains RTLD_GLOBAL)? What
kind of file extension does it requires or appends: *.bundle, *.dylib or *.so on MacOSX?
If you think that plugins can easily be made working on MacOSX, please patch plugin.c
first if needed (and propose that to the trunk), by taking care of at least naming the
suffix needed for them (in a publicly available header exported to plugins), then
melt-runtime.h could use that.


This .so suffix is hardwired in melt-runtime.c; I am adding MELT_DYNLOADED_SUFFIX
constant to help going to systems with other dlopen-ed dynamic libraries suffixes.

I added your SHARED_LIBRARY_FLAGS patch into melt-module.mk

I sadly think that MELT plugin would need autoconf things to be workable on non Linux
systems. But I really don't know autoconf (actually, I hate it) and don't know how to
start working on that. Can you help?

I just commited svn rev 186039 of MELT branch with some of your and mine changes.

I still need to replace the occurrences of .so in the MELT code itself.

Thanks.
-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***

Re: [GCC-MELT-391] MELT 0.9.5rc1 etc...

[Romain Geissler]

Le 31 mars 2012 à 12:27, Basile Starynkevitch a écrit :

> I am surprised of your patch which indeed contains gcc/melt-build.tpl:
> 
> -## GAWK is needed, the GNU awk [+ (. (tpl-file-line))+]
> -GAWK ?= gawk
> +## AWK is needed [+ (. (tpl-file-line))+]
> +AWK ?= awk
> 
> 
> I really need GNU awk (and I may depend upon GNU extensions of awk). AFAIK, GCC also
> requires *GNU* awk specifically (and not some other awk). Why the above patch? If GNU awk
> is called awk on MacOS (like it is on some Linux distributions) just call it still GAWK in
> makefile things! I'm pretty sure to not be the only one with this convention, that GAWK in
> Makefile meen that GNU extensions of awk is necessary.

Are you sure you really need GNU awk ? I don't think so ! In my patch, i replaced every GAWK
uses in Melt (only the melt files that you ship in the packaged version of Melt, there are still
somes instances of Gawk in /contrib/MELT-Plugin-Makefile and in /contrib/build-melt-plugin.sh
but those are only for packagers, not for melt users). The gawk usage i replaced were trivial
uses that DO NOT use specific GNU awk features (on printing and using the {next} command).

I've take a look at the different GCC configure scripts, and it only looks for one awk implementation
in that order : for ac_prog in gawk mawk nawk awk. There is no further check performed to know
if it is GNU awk or not, as all uses are conforming to the common awk specifications.

You may fix my patch so that it first looks for gawk, then mawk, then nawk then finally awk. But
again i'd better see this kind of test in a configure script. Usually, if one awk program exists (may
it be gawk, mawk or nawk) then awk will also do (typically a symlink to the right executable).

On a mac, only the classical awk version is shipped by default by Apple, not GNU awk.

> A more general question is the status of plugins on MacOSX. I thought that GCC plugins in
> general only work for ELF shared object systems with dlopen. It seems that gcc/plugin.c
> is hardwiring the ".so" suffix in function add_new_plugin. Can an unpatched GCC 4.7 (FSF
> distributed) be built on MacOSX with plugins enabled and working?

Plugins works fine on Darwin with an unpatched GCC 4.6 or 4.7, you just need to know that
building a bundle is made with -bundle -undefined dynamic_lookup instead of -shared. My
plugins work, and so does Dragon Egg in the LLVM project.

> Does dlopen as
> specified by Posix: http://pubs.opengroup.org/onlinepubs/009695399/functions/dlopen.html
> etc work on MacOSX (in particular when file is NULL and mode contains RTLD_GLOBAL)?

From the man page shipped by Apple, i see :
If a null pointer is passed in path, dlopen() returns a handle equivalent to RTLD_DEFAULT.

So i think the uses of dlopen made by gcc and melt might work on a mac.

> What
> kind of file extension does it requires or appends: *.bundle, *.dylib or *.so on MacOSX?
> If you think that plugins can easily be made working on MacOSX, please patch plugin.c
> first if needed (and propose that to the trunk), by taking care of at least naming the
> suffix needed for them (in a publicly available header exported to plugins), then
> melt-runtime.h could use that.

No extension is required it could be *.anything. By convention, on Darwin, we should
call those files *.bundle. I'll patch gcc so that it looks for *.bundle instead of *.so. We'll
see if it's accepted.

> This .so suffix is hardwired in melt-runtime.c; I am adding MELT_DYNLOADED_SUFFIX
> constant to help going to systems with other dlopen-ed dynamic libraries suffixes.
> 
> I added your SHARED_LIBRARY_FLAGS patch into melt-module.mk
> 
> I sadly think that MELT plugin would need autoconf things to be workable on non Linux
> systems. But I really don't know autoconf (actually, I hate it) and don't know how to
> start working on that. Can you help?

I might help, just need some time. Building properly melt with a much efficient Makefile
is more important for now, I thinl. I'll keep my specific OSX change for me for now, until
other things work well on ELF platforms (as the only native OS i have is OSX, I don't want
to loose time building GCC in a virtual machine).

> I just commited svn rev 186039 of MELT branch with some of your and mine changes.
> 
> I still need to replace the occurrences of .so in the MELT code itself.
> 
> Thanks.
> -- 
> Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
> email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
> 8, rue de la Faiencerie, 92340 Bourg La Reine, France
> *** opinions {are only mine, sont seulement les miennes} ***

Re: [GCC-MELT-391] MELT 0.9.5rc1 etc...

[Romain Geissler]

Le 31 mars 2012 à 13:55, Romain Geissler a écrit :

> 
> Le 31 mars 2012 à 12:27, Basile Starynkevitch a écrit :
> 
>> I am surprised of your patch which indeed contains gcc/melt-build.tpl:
>> 
>> -## GAWK is needed, the GNU awk [+ (. (tpl-file-line))+]
>> -GAWK ?= gawk
>> +## AWK is needed [+ (. (tpl-file-line))+]
>> +AWK ?= awk
>> 
>> 
>> I really need GNU awk (and I may depend upon GNU extensions of awk). AFAIK, GCC also
>> requires *GNU* awk specifically (and not some other awk). Why the above patch? If GNU awk
>> is called awk on MacOS (like it is on some Linux distributions) just call it still GAWK in
>> makefile things! I'm pretty sure to not be the only one with this convention, that GAWK in
>> Makefile meen that GNU extensions of awk is necessary.
> 
> Are you sure you really need GNU awk ? I don't think so ! In my patch, i replaced every GAWK
> uses in Melt (only the melt files that you ship in the packaged version of Melt, there are still
> somes instances of Gawk in /contrib/MELT-Plugin-Makefile and in /contrib/build-melt-plugin.sh
> but those are only for packagers, not for melt users). The gawk usage i replaced were trivial
> uses that DO NOT use specific GNU awk features (on printing and using the {next} command).

I forgot to add add that the awk usages you perform are so trivial that grep will also fits your needs
and is a lower dependency than awk.

Re: [GCC-MELT-397] MELT 0.9.5rc1 etc...

[Basile Starynkevitch]

On Sat, 31 Mar 2012 14:02:45 +0200
Romain Geissler <romain.geissler@gmail.com> wrote:

> 
> I forgot to add add that the awk usages you perform are so trivial that grep will also fits your needs
> and is a lower dependency than awk.


I am not sure of that. MELT need several awk scripts, make-melt-predefh.awk &
make-warmelt-predef.awk which probably uses some GNU things. (I think that printf in AWK
script is a GNU extension).

Cheers



-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***

Re: [GCC-MELT-397] MELT 0.9.5rc1 etc...

[Jonathan Wakely]

On 31 March 2012 13:38, Basile Starynkevitch wrote:
>
> (I think that printf in AWK script is a GNU extension).

Nope, it's standard.

Re: [GCC-MELT-397] MELT 0.9.5rc1 etc...

[Romain Geissler]

Le 31 mars 2012 à 15:07, Jonathan Wakely a écrit :

> On 31 March 2012 13:38, Basile Starynkevitch wrote:
>> 
>> (I think that printf in AWK script is a GNU extension).
> 
> Nope, it's standard.

Yeah it is. I looked at your the melt files in contrib (that's quite
strange that the Makefile used to build the melt plugin is
located in here through, files in the contrib directory should
not be mandatory to build gcc !).

It seems that among all your gawk uses, including
make-warmelt-predef.awk and make-melt-predefh.awk
the only GNU specific feature is strtonum. But you don't need it,
as the following works with regular awk :

echo 4.7.0  | awk '{split($1,vertab,"."); printf "%d", vertab[1]*1000+vertab[2]}'

By looking at your awk calls, i think you've got some errors in
MELT-Plugin-Makefile at the following line:

MELTGCC_VERSION := $(shell env LANG=C LC_ALL=C $(MELTGCC) -v < /dev/null 2>&1 | $(GAWK) "/^gcc version/{print $$3}")

Notice the $$3 at the end, showing you only need the version number.
This line currently outputs something like:
gcc version 4.7.0 20120115 (experimental) (GCC)

If you change double quote by single quote like this:
MELTGCC_VERSION := $(shell env LANG=C LC_ALL=C $(MELTGCC) -v < /dev/null 2>&1 | $(GAWK) '/^gcc version/{print $$3}')

It'll output:
4.7.0

If you change this, then you'll also have to change this line:
echo "$(MELTGCC_VERSION)"  | $(GAWK) '{split($$3,vertab,"."); printf "%d", strtonum(vertab[1])*1000+strtonum(vertab[2])}' > $@

to this:
echo "$(MELTGCC_VERSION)"  | $(GAWK) '{split($$1,vertab,"."); printf "%d", strtonum(vertab[1])*1000+strtonum(vertab[2])}' > $@

(notice $$3 becomes $$1)

Romain Geissler

Re: [GCC-MELT-397] MELT 0.9.5rc1 etc...

[Basile Starynkevitch]

On Sat, 31 Mar 2012 15:55:50 +0200
Romain Geissler <romain.geissler@gmail.com> wrote:

> Le 31 mars 2012 à 15:07, Jonathan Wakely a écrit :
> 
> > On 31 March 2012 13:38, Basile Starynkevitch wrote:
> >> 
> >> (I think that printf in AWK script is a GNU extension).
> > 
> > Nope, it's standard.
> 
> Yeah it is. I looked at your the melt files in contrib (that's quite
> strange that the Makefile used to build the melt plugin is
> located in here through, files in the contrib directory should
> not be mandatory to build gcc !).

No, it is not strange: indeed the MELT *branch* has a file contrib/MELT-Plugin-Makefile
which is used for the *MELT* plugin (but is useless for the MELT *branch*, which has its
own gcc/Makefile.in).

But the MELT plugin is not useful for the MELT branch. When you build a gcc-melt from the
MELT branch, there is no melt.so file involved, the melt-runtime.o is statically linked
inside cc1 (and cc1plus, etc etc...) and the MELT runtime is automagically started as a
pseudo-plugin without any dlopen-ing. the MELT initialization phase is indeed dlopen-ing
MELT modules (as does the melt.so plugin for a regular GCC), because toplev.c of the MELT
branch calls melt_initialize() and melt_finalize().

So, when building the MELT *branch* (which few people do), you don't need or use
contrib/MELT-Plugin-Makefile.

When I extract the MELT plugin from the MELT branch (e.g. for MELT plugin releases) with
the procedure in https://groups.google.com/group/gcc-melt/msg/083091abb7f30c39?hl=en the
MELT-Plugin-Makefile is becoming the Makefile for the extracted plugin. But the MELT
branch don't need it, so it sits in rightly contrib/MELT-Plugin-Makefile


> It seems that among all your gawk uses, including
> make-warmelt-predef.awk and make-melt-predefh.awk
> the only GNU specific feature is strtonum. But you don't need it,
> as the following works with regular awk :
> 
> echo 4.7.0  | awk '{split($1,vertab,"."); printf "%d", vertab[1]*1000+vertab[2]}'
> 
> By looking at your awk calls, i think you've got some errors in
> MELT-Plugin-Makefile at the following line:
> 
> MELTGCC_VERSION := $(shell env LANG=C LC_ALL=C $(MELTGCC) -v < /dev/null 2>&1 | $(GAWK) "/^gcc version/{print $$3}")

Corrected and commited svn rev 186044.

Thanks
-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***

Announce: MELT 0.9.5rc2 release candidate (for GCC 4.6 and 4.7)

[Basile Starynkevitch]

Hello All,

It is my pleasure to announce the MELT plugin 0.9.5 release candidate 2 for GCC 4.6 or 4.7.

################################################################
NEWS for 0.9.5rc2 MELT plugin for GCC 4.6 & 4.7
[[April 2nd 2012]] release candidate 2

   Alternative infix syntax is abandoned (it was never implemented)

   Accept $(sub sepxr) in macro-string and $[seq sepxr]

   Handle SIGIO Unix signals with asynchronous input channels
   (experimental feature)

   Can be compiled by C++ (since GCC 4.7 often is)

   All the values are translated to melt_ptr_t variables, not void*
   ones.
 ###############################################################

I believe it should work for a GCC 4.7 compiled in C++ mode.
Thanks to Alexnadre Lissy & Romain Geissler for their help.

Please test and report bugs or build success or failure on
gcc-melt@googlegroups.com list.

Regards.

-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

Re: Announce: MELT 0.9.5rc2 release candidate (for GCC 4.6 and 4.7)

[Basile Starynkevitch]

On Mon, Apr 02, 2012 at 12:30:51PM +0200, Basile Starynkevitch wrote:
> Hello All,
> 
> It is my pleasure to announce the MELT plugin 0.9.5 release candidate 2 for GCC 4.6 or 4.7.

MELT is a high-level domain specific language to extend GCC
 
> ################################################################
> NEWS for 0.9.5rc2 MELT plugin for GCC 4.6 & 4.7
> [[April 2nd 2012]] release candidate 2
> 
>    Alternative infix syntax is abandoned (it was never implemented)
> 
>    Accept $(sub sepxr) in macro-string and $[seq sepxr]
> 
>    Handle SIGIO Unix signals with asynchronous input channels
>    (experimental feature)
> 
>    Can be compiled by C++ (since GCC 4.7 often is)
> 
>    All the values are translated to melt_ptr_t variables, not void*
>    ones.
>  ###############################################################
> 
> I believe it should work for a GCC 4.7 compiled in C++ mode.
> Thanks to Alexnadre Lissy & Romain Geissler for their help.
> 
> Please test and report bugs or build success or failure on
> gcc-melt@googlegroups.com list.


Sorry, I forgot the download information

The release candidate 2 of MELT plugin 0.9.5 is still perhaps buggy but is available from 
http://gcc-melt.org/melt-0.9.5rc2-plugin-for-gcc-4.6-or-4.7.tar.gz 
as a gzipped tar archive of 4476348 bytes and md5sum 75e528535b05a03f452b55018b6b085b. 
You could try building it e.g. with 
     make CC=gcc-4.7 CXX=g++-4.7 
or perhaps with 
    make MELTGCC=gcc-4.7 GCCMELT_CC=g++-4.7.

 Please report bugs on gcc-melt list. It is extracted from MELT branch svn revision 186078, april 2nd 2012.

Cheers.
-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***