[M3devel] Arch-independent derived files (Re: multiarch)

[Jay K]

ps: ccache is something that kind of goes this automatic way, but for different reasons and not really applicable. It is looking for opportunistic identicalness and really striving for the strongest definition of identical.
 
 - Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: mika at async.caltech.edu; rodney.m.bates at cox.net
> CC: m3devel at elegosoft.com
> Subject: RE: [M3devel] Arch-independent derived files (Re: multiarch)
> Date: Tue, 7 Jul 2009 21:48:47 +0000
>
>
> Um, to repeat myself, I think outputs should all be under a common root, not strewn around the source tree as they are.
>
>
> The documentation claims there is already a nice source/output separation, but that is only for each package, not across multiple packages.
>
>
> So you could do
>
> export CM3_OBJ_ROOT=/tmp/$USER/obj/cm3/1 unshipped files like .o go here
> export CM3_INSTALL_ROOT=/bin/cm3/1 shipped files like .so go here
> ./do-cm3-std.py buildship
>
>
> export CM3_OBJ_ROOT=/tmp/$USER/obj/cm3/2 unshipped files like .o go here
> export CM3_INSTALL_ROOT=/bin/cm3/2 shipped files like .so go here
> ./do-cm3-std.py buildship
>
> etc.
>
> ship already works this way -- CM3_INSTALL is the variable name, not my favorite. I tend to think "ROOT" should be in there.
>
> The "problem" is that compile/link don't.
>
> Some systems hash something, like the environment, the command line, the compiler and its dependencies (down to the kernel and loaded kernel drivers/modules?) and put that somewhere in the path.
>
> MPW's MABuild (MacAppBuild) in particular did something that -- not down the down compiler/dependencies/kernel, but I think the command line.
>
> Then you'd just
> export CM3_OBJ_ROOT=/obj/cm3 and the rest would be automatic.
>
> However you get stuck in the "what is the same? What is different?" dilemna.
> What if I want to not optimize just some particular code I am debugging?
> It should still go along with all the rest of the code.
> What if change the compiler to trace some stuff just so I can better understand one particular source file. Ditto.
>
>
> Probably the "hash" overridable from the command line.
> But you still want good defaults.
>
>
> I have not seen this automatic approach used much.
> But certainly the idea of one output root is good.
> Certainly the original authors were thinking this way, they just stopped way short.
>
>
> - Jay
>
>
>
>
>
> ----------------------------------------
>> To: rodney.m.bates at cox.net
>> Date: Tue, 7 Jul 2009 14:16:00 -0700
>> From: mika at async.caltech.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] Arch-independent derived files (Re: multiarch)
>>
>> Going in the "other direction" it might be nice to have different
>> derived directories for different compilers, e.g., CM3 and PM3, or
>> different versions of CM3.
>>
>> Not something that is really necessary for anyone, I'm sure, but
>> it seems like a flexible mechanism for "derived" directories might
>> be able to handle that too...
>>
>> Mika
>>
>> "Rodney M. Bates" writes:
>>>This may only be peripherally related, but since this discussion
>>>has come up:
>>>
>>>I have long wished for a directory, neither src, nor the architecture
>>>directory, for files that are mechanically generated but not
>>>target dependent. I have an application where there are several
>>>machine-generated files containing Modula-3 "source" code.
>>>
>>>It's "source code", in the sense that it is input to the compiler, but not
>>>"source code", in the sense that it is not written by a human using
>>>an editor. Some existing quake commands for instantiating generics
>>>do similarly. Neither place is entirely appropriate for these files.
>>>
>>>I have gone through a series of kludgy ways of handling this. Right
>>>now, I have them in a directory "derived", beside "src", with lines in
>>>m3makefiles that look, e.g., like:
>>> 'implementation("../derived/M3InitTokStrings")'.
>>>
>>>But the instantiating quake functions put generated source code in
>>>the arch directory, and sometimes unnecessarily regenerate it.
>>>
>>>Just something that it would be nice to clean up.
>>>
>>>hendrik at topoi.pooq.com wrote:
>>>> It seems relevant to out multiarchitecture system that Debian and Ubuntu
>>>> are currently also struggling to put together a multiarchitecture
>>>> system.
>>>>
>>>> Current thinking seems to be posted at
>>>> https://wiki.ubuntu.com/MultiarchSpec
>>>>
>>>> The stimulus for this work seems to be having 32-bit and 64-bit programs
>>>> coexist on the same AMD-64 system. But it also deals with questions
>>>> like MIPS systems having at least three different ABIs.
>>>>
>>>> Have a look.
>>>>
>>>> -- hendrik
>>>>
>>>>
>>>>