Re: [edk2-buildtools] Where is python code that generates the object_files.lst file?

[Andrew F. <af...@ap...>]

Ken,

Sorry catching up from my vacation.

I had to move away from using cygwin on a day to day basis as it was hanging way too often doing builds.  There was a mail thread earlier in the year where we talked about known dead locks in cygwin, and the way the edk2 does threading in python seem to cause a lot of issues.

I agree that bash everywhere is a good answer in general. 

The problem is not the shell, the problem I'm having is with the compilers and tools I'm trying to port. The ARMCC compiler does not recognize cygpaths, so we can not use the $(OBJECT_FILES_LIST) file. The CodeSourcery GCC compiler make, and gcc don't seem to understand cygpaths either, and can't use the Windows paths in its $(OBJECT_FILES_LIST) file.

Andrew Fish





On Jun 11, 2010, at 9:35 AM, Lu, Ken wrote:

> Andrew:
>          The usage of cygwin has two ways:
> 1)       Only need cygwin1.dll in your environment path, and run something from dos command. Then dos like path “\” could use directly.
> 2)       Under cygwin shell environment, then “/” could use.
>  
> I think the better way is under cygwin shell environment, which is most like linux environment.
>  
> Ken
>  
> From: Huang, Qing [mailto:qin...@in...] 
> Sent: Friday, June 11, 2010 4:22 PM
> To: Andrew Fish; edk...@li...
> Cc: edk...@li...
> Subject: Re: [edk2-buildtools] Where is python code that generates the object_files.lst file?
>  
> Andrew,
>  
> The python code should reside in line 529~536 of AutoGen/GenMake.py.
>  
> Thanks & Best regards,
> Huang, Qing
>  
> From: Andrew Fish [mailto:af...@ap...] 
> Sent: Friday, June 11, 2010 1:35 AM
> To: edk...@li...
> Cc: edk...@li...
> Subject: [edk2-buildtools] Where is python code that generates the object_files.lst file?
>  
> I can't use this file for cygwin builds as it contains the wrong form of path. Also the Code Sourcery GCC for ARM does not like paths with \. I'd like to update to use / in place of \ and possibly generate cygwin compatible names if possible. 
>  
> This should make it possible to simplify the build_rule.template file...
>  
> Andrew Fish
>  
> [Static-Library-File]
>     <InputFile>
>         *.lib
>  
>     <ExtraDependency>
>         $(MAKE_FILE)
>  
>     <OutputFile>
>         $(DEBUG_DIR)(+)$(MODULE_NAME).dll
>  
>     <Command.MSFT, Command.INTEL>
>         "$(DLINK)" /OUT:${dst} $(DLINK_FLAGS) $(DLINK_SPATH) @$(STATIC_LIBRARY_FILES_LIST)
>  
>     <Command.GCC>
>         "$(DLINK)" -o ${dst} $(DLINK_FLAGS) -\( $(DLINK_SPATH) @$(STATIC_LIBRARY_FILES_LIST) -\) $(DLINK2_FLAGS)
>         "$(OBJCOPY)" $(OBJCOPY_FLAGS) ${dst}
>  
>     <Command.ARMGCC>
>         "$(DLINK)" -o ${dst} $(DLINK_FLAGS) -( $(DLINK_SPATH) $(STATIC_LIBRARY_FILES) -) $(DLINK2_FLAGS)
>  
>     <Command.RVCT>
>         "$(DLINK)" $(DLINK_FLAGS) -o ${dst} $(DLINK_SPATH) --via $(STATIC_LIBRARY_FILES_LIST) $(DLINK2_FLAGS)
>  
>     <Command.RVCTCYGWIN>
>         #$(STATIC_LIBRARY_FILES_LIST) has wrong paths for cygwin
>         "$(DLINK)" $(DLINK_FLAGS) -o ${dst} $(DLINK_SPATH) $(STATIC_LIBRARY_FILES) $(DLINK2_FLAGS)
>  
>     <Command.XCODE>
>         "$(DLINK)" $(DLINK_FLAGS) -o ${dst} $(DLINK_SPATH) -filelist $(STATIC_LIBRARY_FILES_LIST)  $(DLINK2_FLAGS)
>  
>  
> 
> 
> Andrew Fish
>  
>  
>  
> 
>