[M3devel] platform names again.

[Jay K]

Yes BUILD_DIR apparently is meant to be overridable/changable.
I'm not sure if all the various tools that kinda sorta know what is going on will play along.
When I pointed out that TARGET does not necessarily equal BUILD_DIR, Randy said that would break cm3ide.
Yet it was apparently always theoretically true, for profiled builds.
  Not that I have done a profiled build.
And it is always true in practise.
  Since I never do a profiled build and probably nobody else does either.
But you can try varying it.
 
 
Try this:
 
in config file, change
BUILD_DIR = whatever
to
if !defined("BUILD_DIR)" around
BUILD_DIR = whatever
end
 
 
and then on the cm3 command line, try cm3 -DBUILD_DIR=foo
 
 
scripts -realclean will tend to not play along here.
 
 - Jay


----------------------------------------
> Date: Mon, 24 Aug 2009 19:31:18 -0400
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] platform names again.
>
> On Mon, Aug 24, 2009 at 08:58:56PM +0000, Jay K wrote:
>>
>> I'm not sure that is true.
>> I know some of the BSDs sometimes carry compatibility libraries -- old versions of libc.
>> I'm not sure the struct sockaddr is a libc change or a kernel change.
>> The mention in the release notes sounds like possibly a kernel change.
>>
>>
>> I find the level of incompatibility knowingly introduced surprising in some of these systems.
>> The commercial systems all seem to try and do achieve much better.
>>
>>
>> As to more of the original questions, no, I don't think there is much
>> you can do about the "LINUXLIBC6" directory name, in the distributed
>> packages. For when you build from source, BUILD_DIR and TARGET are
>> strictly speaking separate values. BUILD_DIR perhaps should be more
>> fine grained and include more of uname.
>
> So does TARGET identify the target platform and does BUILD_DIR identify
> the name of the directory (in this case .../LINUXLIBC6/ ) into which all
> the derived files should go? Could BUILD_DIR be overridden? That would
> suffice. I'd just pick a different BUILD_DIR when I compile on one of y
> systems.
>
>>
>>
>> Ultimately we may very well go back to a release form of:
>> assembly code for all the Modula-3 code, that goes into just cm3
>> uncompiled C code, again just what cm3 uses
>> a makefile
>> source to everything else
>>
>>
>> That will address this issue.
>>
>>
>> And then specific builds for specific systems, like Debian 4.0, Debian 5.0, OpenSUSE 11.0, Fedora 10, etc., the small number we can afford to provide -- possibly in the generic form, possibly in rpm/deb format as the systems "prefer" -- note that this is two separate variables -- the packaging format and the actual ABI.
>>
>>
>> It would be good to nail this all down with more certainty -- what actually has changed in the past and/or is likely to change in the future. I wish the set was empty, but 64bit FreeBSD provides enough of an example to prove it is not.
>>
>>
>> But, I have to ask, how the check do things like Adobe Flash, Acrobat
>> Reader, etc. work?
>
> Every now and them Adobe Flash just stops working altogether on my
> system.
>
> -- hendrik