Re: Is there any way to use ARC in 32-bit?

[Richard Frith-Macdonald]

On 31 Jan 2015, at 15:08, Riccardo Mottola <riccardo.mottola@libero.it> wrote:
> 
> Hi,
> 
> David Chisnall wrote:
>> Aside from GNUstep itself, there are very few projects using autoconf and 
>> GNUstep Make and for GNUstep the autoconf code does a load of redundant 
>> work, takes longer to run than the entire build, and doesn't properly inject 
>> itself into the generated dependency graph, so you end up having to gmake 
>> distclean periodically to get it to work, and when it does rerun itself it 
>> forgets all of the configuration options and you end up with a broken build.
> yes, that is a bug in gnustep.make. configure caches its option in 
> "config.status".
> So, if configure changes, one should run:
> ./config.status --recheck && ./config.status
> 
> since gnustep make is broken, I have grown that command in muscular memory 
> and retype it before make tries to.
> It is very important, because that way you preserve typical options in 
> building gnustep base or gui itself (e.g. layout, prefix....) which can mess 
> your gnustep configuration.
> If make just runs "./configure" like it does, you will loose also trace of 
> your previous settings, making a mess.
> 
> There is also a way to reuse in sub-projects configure tests run at a higher 
> level, I don't remember how thouh.
> 
> Someone should indeed try to "patch" this behaviour.

You run configure to configure gnustep-make, but I was not under the impression 
that gnustep-make called configure.
It's therefore hard to see, unless I've missed something, how there would be 
such a bug in gnustep-make.

There's a lot of misinformation about gnustep-make in David's posts, so much 
that I can't take time to address it all ...
so please don't assume that something is an issue with gnustep-make just 
because you read it in this thread.

You didn't give much detail, but my guess is that you are running in to a 
feature of some of the core libraries;
There are makefiles people have written which call configure automatically if 
it hasn't been called already (so that
a user needs only type 'make install' rather than having to run configure 
first).
The core libraries at least do that, but it's not a behavior of gnustep-make 
and wouldn't occur for other apps/packages.
That's a case of us prioritising ease of use for the beginner (someone who 
wants to download gnustep code and get
started as easily as possible) over ease of use for someone who frequently 
hacks around and changes things.
I think we just added a little check to see if the 'configure' script had been 
changed more recently than the build,
and reconfigure if it has.  I think also we (core developers) decided that in 
them event of a config change doing
a fresh config was more likely to give good results than re-using old config 
settings.  That could just be a bad
judgment call?