11-22-2010 12:35 PM
have a need to be able to perform a complete build of the software for a MicroBlaze project from within a batch file.
The system.xml file for the design is available as an input, and is in a known location. The source code and the project files for both the platform and application are populated from our source code control archive.
I figured out how to run libgen, and it builds the platform libraries needed based on the system.xml file.
What I'm having problems with is figuring out how to run the managed make portion to create the build configuration directory and all the makefiles it takes to produce the elf file. Once that's done I can run 'make -q main-build' and get the elf file at the end just fine.
After digging around here and in the eclipse forums, the closest thing I found was to run eclipse in 'headless' mode using some variation of the following command:
C:\Xilinx\11.1\EDK\eclipse\bin\nt\eclipse -nosplash -application org.eclipse.cdt.managedbuilder.core.headlessbuild -data %WS_ROOT_DIR% -import %PROJ_ROOT_DIR%/ -cleanBuild %PROJNAME%
Unfortunantly, the version of eclipse provided with the SDK (I'm using version 11.4 of the Xilinx tools, BTW) does not appear to include the headless build application.
Does anyone know how to do this?
Do I need to convert into an unmanaged C project and just archive the makefiles?
12-01-2010 11:01 AM
Anyone got anything at all?
I really can't believe I'm the only one to run into this problem.
12-15-2010 04:01 PM
Have updated to version 12.3 of the Xilinx tools, and still have no answer.
Additionally, the external builder provided with 12.3 does not function correctly on a windows platform, and running an external make using the provided cygwin tools is no longer possible due to targets in the generated makefiles containing a "C:", which make rejects with the following error message:
Running make in C:\Work\SWIR_Test\SWIR_SSC\Release:
GNU Make 3.81
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
This program built for i686-pc-cygwin
Reading makefile `makefile'...
Reading makefile `../makefile.init' (search path) (don't care) (no ~ expansion)...
Reading makefile `sources.mk' (search path) (don't care) (no ~ expansion)...
Reading makefile `subdir.mk' (search path) (don't care) (no ~ expansion)...
Reading makefile `src/subdir.mk' (search path) (don't care) (no ~ expansion)...
Reading makefile `FreeRTOS/Source/subdir.mk' (search path) (don't care) (no ~ expansion)...
FreeRTOS/Source/subdir.mk:26: *** target pattern contains no `%'. Stop.
An error occurred: build failed!
FreeRTOS is a linked folder, which can only be defined with an absolute path, or with a workspace variable that resolves to an absolute path.
Why does the provided makefile generator output makefiles that cannot be processed without user intervention to fix things up?
12-16-2010 07:24 AM
Once you use a linked folder, the Makefiles will start having the "C:" style paths that don't work with cygwin make. Your only recourse is to use relative or fully /cygdrive/c style paths instead of using linked folders.
For this reason, we have moved away from Cygwin in 13.1 and gone to MingW. The MingW make should support such configurations.
After you move to /cygdrive/c style paths, you shouldn't have any trouble building from the command line.
12-16-2010 10:59 AM
Thanks for the information, vsiva.
I'd actually prefer to use all relative paths, as that is how to guarantee that the build is location independent when someone else needs to work on the project - or in my case need to run an automated build process.
The only problem with relative path specifications is that I can't seem to find a way to specify a relative path for a linked folder: all the dialogs that allow specification of the linked resource appear to require an absolute path, which always ends up with the "C:\" windows-style path convention - including using path variables, which should have been able to do this IMHO.
If there were a way to regenerate the makefiles from the command line (i.e. do an eclipse 'headless' build) based on local build information like either the workspace or project location, this would be OK - but without that I then need to archive the makefiles - but need to do so without the absolute path expansion that the workbench performs when it creates them..
So although I believe that changing from DOS to POSIX style paths would work for an individual build that can rely on absolute paths, it's really not a good solution to my problem.
12-16-2010 11:09 AM
What works for me is to write my own makefiles. I let XPS build the Xilinx libraries the way that it wants to and I have my own makefiles for building my application against those libraries. That way I don't have to fight the GUI tools to do what I want.
12-16-2010 11:21 AM
Personally, I'd write my own Makefiles, but there are many people who want these Makefiles to be generated.
When the Makefiles are generated, ideally you would not store them in version control as they are a generated artifact, and you'd typically only store sources in version control.
In your case, the main problem is the use of linked folders. Figure out how you can structure your projects so that you can do without using linked folders. If you use them, it will always lead to conflicts with cygwin make. As we've learnt, Eclipse and Cygwin don't play well together - Eclipse insists on following the OS's standards, while Cygwin insists on being faithful to Unix. That is why we've moved to MingW, but that is only in 13.1.
In the meantime, I'd structure your projects like this:
Put all of them in 1 folder, and then whenever you need to reference your RTOS from the app, use relative paths. See attached document for more details on how to do source control with SDK.
The Eclipse headless command generates Makefiles, so you shouldn't have to save them. Ofcourse if you write your own Makefiles, then you get the best scenario of never having to rely on Eclipse - you only rely on it for all its source cross referencing and graphical debuggers..
12-16-2010 06:37 PM
Thank you again for your input, especially the document - on which I have a question, since it appears it has a potential answer to one of my original questions.
On page 15 of the document, there is an example on how to build an application from the command line, which is the issue I originally set out to resolve.
Unfortunantly, the screen capture used in the PDF file has truncated the command line, so there's no way to determine specifically what the correct argument to "-application" should be. Could you either post that information here, or a link to where the information could be found, please?
Concerning using an exernal makefile system, this could (obviously) be used, but is undesireable because not all developers are created equal: I've seen subtle and hard to diagnose bugs occur due to unintentionally malformed makefile changes due to one person who didn't understand makefiles check in a 'simple' change. If the tools are able to consistently and correctly create the makefiles needed, it's a definite plus.
12-17-2010 10:08 AM
Sorry about that. Here it is:
12-17-2010 06:17 PM
Thanks again, I haven't had time to work with this today, I'll give it a try on Monday and let you know if I have any additional questions.
08-03-2011 01:13 PM
I was working on a similar problem today and the commands posted in this thread worked great for me. Thanks!!!
08-04-2011 06:44 AM
I do have one problem with the make script. If there is an error in the build, a GUI pops up indicating that "Java was started but returned exit code=1". This hangs indefinitely until the user clicks on OK. So, the solution above it not completely headless.
Anybody know how to get rid of this GUI and yet still get the fact that the build failed?
08-04-2011 07:36 AM
After some digging I discovered that the following command line option will suppress the dialog from popping up:
06-10-2013 01:58 PM
I came across this message thread during the search for the commands to build the Xilinx SDK project outside SDK. Basically I need to create a windows batch file script to build the software from a command line. I'm using Xilinx 13.2 with Eclipse CDT 7.0.2
@williamhhowell: Were you able to build the software from the command line? Any updates, I'd highly appreciate!
@vsiva: Based on the 'Xilinx SDK Command Line Flows' document and your inputs, I've made the windows batch script below to do build.
%ECLIPSE% -vm %VM% -nosplash -application org.eclipse.cdt.managedbuilder.core.headlessbuild -importAll %PROJ_DIR% -data %WORKSPACE% -vmargs -Dorg.eclipse.cdt.core.console=org.eclipse.cdt.core.systemConsole
%ECLIPSE% -vm %VM% -nosplash -application org.eclipse.cdt.managedbuilder.core.headlessbuild -build %BSP_DIR% -data %WORKSPACE% -vmargs -Dorg.eclipse.cdt.core.console=org.eclipse.cdt.core.systemConsole
%ECLIPSE% -vm %VM% -nosplash -application org.eclipse.cdt.managedbuilder.core.headlessbuild -build all -data %WORKSPACE% -vmargs -Dorg.eclipse.cdt.core.console=org.eclipse.cdt.core.systemConsole ==================================================
I could see the Debug and Release directories with the makefiles. But I couldn't create the build output executable .elf file. It seems it doesn't even create any object files.
Attached is the log file generated after executing the script.
My Project workspace is organized as:
I couldn't get the BSP created inside the src folder; so it's outside the 'src' folder inside the workspace.
APP is a simple application project with a single source file just returning 0 in the main(). There's no reason for an application build error and it compiles fine with the SDK GUI.
I have all the files as mentioned in the 'Using SDK with Revision Control Software' document in each of these projects.
How do I create the .elf executable from the build? Can you provide some inputs to building the software on windows? Thanks for any help!
07-25-2013 07:52 PM
@ajose: I face the exact same problem than you are. Did you manage to find a way to build .elf executables?
07-29-2013 11:11 PM