Re: [tools-dev] bridges: building more directories in source/cpp_uno/...

2007-04-02 Thread Hans-Joachim Lankenau 
hi!

a possible way to solve such kind of conflics is to define different
output directories.

in your case this could be achieved by e.g.

SLO+:!=$(SLO)$/$(wherever_you_got_intel_and_powerpc)
RSLO+:!=$(RSLO)$/$(wherever_you_got_intel_and_powerpc)

in the local makefile and using plain SLO for the universal output.

the downside is that when changing something as basic as SLO, i'm quite
sure a couple of pitfalls are waiting for you...

tschau...

ause

Pavel Janík wrote:
 Hi,
 
 I'm working on universal binaries for Mac OS X and have an interesting
 problem to solve ;-)
 
 Bridges contain directories like
 
 bridges/source/cpp_uno/gcc3_macosx_intel
 bridges/source/cpp_uno/gcc3_macosx_powerpc
 
 etc.
 
 I extended it to contain
 
 bridges/source/cpp_uno/gcc3_macosx_universal
 
 as well. This directory is built *after* first two dirs mentioned above
 and creates universal binary by combining the output from these
 directories.
 
 It works, sort of ;-)
 
 The problem is that intel dir contains:
 
 SLOFILES= \
 $(SLO)$/except.obj\
 $(SLO)$/cpp2uno.obj\
 $(SLO)$/uno2cpp.obj \
 $(SLO)$/call.obj
 
 and powerpc:
 
 SLOFILES= \
 $(SLO)$/except.obj\
 $(SLO)$/cpp2uno.obj\
 $(SLO)$/uno2cpp.obj
 
 So these three files are shared.
 
 This brings some interesting issues like parallel build issues, ordering
 issues (if the Intel is built first, PPC files are not built) etc. Is
 there any way to solve this issue *without* renaming the files? My goal
 is to not change the name of these files, I do not care about parallel
 build issues right now. Good enouhg (for now) fix for me would be one of:
 
 - remove $SLOFILES after the TARGET is created
 - touch source files *before* the TARGET is created
 
 Or?
 
 I simply feel that renaming is the proper solution here, but is there
 any other solution available?
 --Pavel Janík
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [tools-dev] bridges: building more directories in source/cpp_uno/...

2007-04-01 Thread Martin Kretzschmar 

On Mar 31, 2007 11:33 AM, Pavel Janík [EMAIL PROTECTED] wrote:

Bridges contain directories like

bridges/source/cpp_uno/gcc3_macosx_intel
bridges/source/cpp_uno/gcc3_macosx_powerpc

etc.

I extended it to contain

bridges/source/cpp_uno/gcc3_macosx_universal

as well. This directory is built *after* first two dirs mentioned
above and creates universal binary by combining the output from these
directories.

It works, sort of ;-)

The problem is that intel dir contains:

SLOFILES= \
 $(SLO)$/except.obj \
 $(SLO)$/cpp2uno.obj\
 $(SLO)$/uno2cpp.obj \
 $(SLO)$/call.obj

and powerpc:

SLOFILES= \
 $(SLO)$/except.obj \
 $(SLO)$/cpp2uno.obj\
 $(SLO)$/uno2cpp.obj

So these three files are shared.


I probably misunderstand something, but isn't almost the whole tree
(except gcc3_foo) shared? How do you handle that?

Martin

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [tools-dev] bridges: building more directories in source/cpp_uno/...

2007-04-01 Thread Pavel Janík 

Hi,


I probably misunderstand something, but isn't almost the whole tree
(except gcc3_foo) shared? How do you handle that?


yes, it is. But it is not a problem there, because it can be compiled  
to universal binary in one step without problem.


Exactly this except gcc3_foo is a problem because the logic says  
none needs to compile more than one of these directories. Except on  
Mac OS X when you need to compile both intel and powerpc directories  
and this is the source of my problems.

--
Pavel Janík


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]