[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Texmacs-dev] nogencc-0.10
From: |
David Allouche |
Subject: |
Re: [Texmacs-dev] nogencc-0.10 |
Date: |
Wed, 15 May 2002 09:58:07 +0200 |
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 --