[gccsdk] [GCCSDK commit] jjvdgeer - r4136 - trunk/autobuilder/develop/vala

Peter Naulls peter at chocky.org
Tue Sep 29 13:14:33 PDT 2009


Jan-Jaap van der Geer wrote:
> Peter Naulls wrote:

>> You need to adjust your patches so they have #if __riscos__ wrappers.
>> You would need to do that anyway, if you were planning to submit
>> upstream.  Then you can use the same source for the native and
>> cross builds.
> 
> Either I don't understand or I think it is not going to work.
> 
> I think you're suggesting the patches will contain these #if __riscos__ wrappers. I checked the FAQ and 
 > although Vala has a minimal preprocessor, it has #if, but no #define and
> as far as I know no predefined values. However, the valac executable has a -D to 
define
 > preprocessor stuff, so it would be possible to define __riscos__ 
within the
> makefile. 

Yes, you would definitely not be using a #define here, even for C.  In
the case of GCC, it internally defines __riscos__, but you could easily
arrange for the makefile to pick up an environment variable which you
set when calling ro-make/make in setvars and is then passed as -D.


> 
> But that is not the main issue. As the patches operate on the .vala files, the 
> .vala files will be newer than the .c files which are generated from the .vala files 
 > (they are just supplied so you do not need a vala compiler to build 
it. A "make clean"
> will remove them...). So "#if __riscos__" or not, the vala compiler will be needed to 
 > compile a native compiler if we are applying the patches before
> building a native compiler. Chicken and egg...

Couple of things you can do here which may help.  One is to build the 
native and cross compiler in different trees from the source; which
configure will generally handle seamlessly for you.   If date stamps are
a problem, you can also play games with 'touch', as some of the builds
do.  Finally, you are free to reverse/reapply patches if necessary.

Note also the procedure in the Firefox build where it applies the
patches itself; although this is partly due to is atypical code
check out.





More information about the gcc mailing list