Re: [Texmacs-dev] nogencc-0.10

[David Allouche]

On Tuesday 14 May 2002 19:10, Joris van der Hoeven wrote:
> On Tue, 14 May 2002, David Allouche wrote:
> > So the definition of the MAKE variable in the base Makefile was not
> > only useless, it was also problematic. Since my new makefiles in the
> > src directory use features specific to GNU make, we must be able to
> > use GNU make recursively even on UNIX systems where it is called
> > gmake.
>
> OK; I assume that the environment variable MAKE is automatically set
> to make if we do not use gmake?

From the SunOS 5.8 man make

     The MAKE macro is another special case.  It  has  the  value
     make by default, and temporarily overrides the -n option for
     any line in which it is  referred  to.  This  allows  nested
     invocations of make written as:

          $(MAKE) ...

     to run recursively, with the -n flag in effect for all  com-
     mands but make. This lets you use `make-n' to test an entire
     hierarchy of makefiles.

From BSD 4.5 man make

     In addition, make sets or knows about the following internal
     variables or environment variables:

         MAKE       The name that make was executed with (argv[0]).

Anyway, and I repeat it to make sure you did not miss the point, the new 
makefiles require GNU make. I might be possible to use automake to 
generate portable makefiles, but I do not want to spend more time on that 
than necessary.

> > So these options just force what is generally the defaut, and prevent
> > the use of more sensible settings in special cases.
>
> Hmm, so why do many people explicitly specify them?
> Again, other suggested me to use these flags...

The only serious reason I can see is to reduce executable size.

Another reason I can see is the joke about the roastbeef with both ends 
cut off.

> > > > Removed --no-rtti option, because it caused a link error with
> > > > gcc-2.95.2.
>
> It should be easy to build a configure test for this problem:
> just check whether compilation of a virtually empty file works
> with this option.

I think it would be more difficult. I just reproduced the problem Debian 
Alpha system on SourceForge.

Objects/instanciations_group.o: In function `editor_rep type_info 
function':
instanciations_group.cc(.text+0x28d04): undefined reference to 
`basic_widget_rep type_info function'
instanciations_group.cc(.text+0x28d08): undefined reference to 
`basic_widget_rep type_info function'
instanciations_group.cc(.text+0x28d20): undefined reference to 
`basic_widget_rep type_info node'
Objects/instanciations_group.o: In function `window_rep type_info 
function':
instanciations_group.cc(.text+0x28d84): undefined reference to 
`ps_device_rep type_info function'
instanciations_group.cc(.text+0x28d88): undefined reference to 
`ps_device_rep type_info function'
Objects/instanciations_group.o: In function `int 
N<string>(array<string>)':
instanciations_group.cc(.rodata+0x310): undefined reference to 
`ps_device_rep type_info node'

Maybe you can tell me what is special about ps_device_rep and 
basic_widget_rep.

If you have a SourceForge account, I will happily give you dev privilege 
on the (previously created) empty project I use to access the compile 
farm.

> Again, you might compare the binaries produce with and
> without this option; if they are identical, then I will
> stop bothering you with this.

I checked.

Normal build:
-rwxr-xr-x    1 david    david     3665256 May 14 13:47 texmacs.bin*

With -fno-rtti:
-rwxr-xr-x    1 david    david     3635912 May 15 08:49 texmacs.bin*

The binaries are obviously different.
The -fno-rtti option reduce the size of the binary by 0.8 %.
Nothing really worth noting.

I'd bet there is no mesurable performance difference either.

> Hmm, I never understood the use of .PHONY,
> but I will take a look when I have time.
> I also remember that there was a way to
> make Cygwin case sensitive:
>
>       export CYGWIN=check_case:strict

That trick may be useful for TeXmacs, but why use a trick to fix a 
makefile problem when there is a specific feature?

> OK, but you might still try to simply start it and wait
> for the error message that you are not allowed to open the display.
> Sometimes execution breaks already before that.

Next time I will go through a compile test round, I will do it.

> You may also contact Michel Costabel for help on Darwin specific
> issues:
>
>       address@hidden

Ok, will do so once we have found a solution to the -fno-rtti problem.
-- 

                                  -- David --