On 02/13/2013 10:44 AM, Olivier Martin wrote:
> Instead of using:
> #if !defined(MDEPKG_NDEBUG)
> (...)
> #endif
>
> It would be better to use:
> DEBUG_CODE_BEGIN();
> (...)
> DEBUG_CODE_END();
>
> The reason is you can be in debug build and disable debug code (and/or
> disable other things such as ASSERT). See definition of PcdDebugPropertyMask
> for the full list of debug properties.
These macros insert code which would place the variable definition
inside an "if" statement. This usage violates the Coding Standard on
page 30:
"The data declarations must be the first code in a module."
"Data declarations appearing anywhere but at the beginning of the
module are illegal."
> The EDK2 coding convention
> (http://sourceforge.net/projects/edk2/files/General%20Documentation/EDK%20II
> %20C%20Coding%20Standards%20Specification.pdf/download) says we should not
> write this kind of variable declaration:
> EFI_STATUS Status = EFI_INVALID_PARAMETER;
>
> See page 30: "Initializing a variable as part of its declaration is
> illegal."
This restriction is violated in almost every case in the files I
patched. I merely coded my changes to blend in with the surrounding
code, as any good maintenance programmer would do.
The coding standard's requirement is, in this case, contrary to commonly
accepted coding practice in the industry for the last decade. It really
should be removed from the DRAFT standard.
The mandatory space between the function name and the opening paren of
its argument list needs to go away too: the vast majority of the
programmers I've spoken with read that as missing a binary operator
between a variable and a parenthized expression. They have to re-read
the code several times before it becomes apparent that this is a
function call and not a coding error. The existence of documented
exceptions (macro definitions, etc.) support the argument that it's a
bad practice.
Feel free to change the patch as you see fit. I never expected to
publish these changes; they were intended only to help me figure out why
I couldn't build a standard target in my development environment. Ryan
asked for copies so I provided them.
-Reece
The attached patch changes the PandaBoardPkg/build.sh script RELEASE
or DEBUG parameter handling.
Before this patch, build.sh can be called thus:
./build.sh
./build.sh -b DEBUG
./build.sh RELEASE
This patch simplifies the way you pass the debug/release parameter
into build.sh so that build scripts can simply pass DEBUG or RELEASE,
without having to create a special case to add the "-b".
Eg.
./build.sh
./build.sh DEBUG
./build.sh RELEASE
Hello all,
This month's Linaro UEFI release is special: it's the first release
from the new tree, using the new process.
The whole thing is documented here; including submission guidelines,
release dates, tree locations, build instructions, ...:
https://wiki.linaro.org/LEG/Engineering/Kernel/UEFI/
The tree can be found here:
http://git.linaro.org/gitweb?p=arm/uefi/uefi-next.git;a=summary
The main points about the new tree:
- The "master" branch is "long lived", it never gets rebased.
- it contains the latest edk2 code from Tianocore
- this is taken directly from the Tianocore GIT, so the SHAs match
- it contains the latest FatDriver2 from Tianocore
- Tianocore does not run a GIT repo for this project
- this is taken from the Linaro GIT mirror of the Tianocore SVN
- it contains the latest BaseTools from Tianocore
- ie. not the version in the edk2 repo but the latest devel code
- this is taken directly from the Tianocore GIT, so the SHAs match
- branches exist for each sub-tree:
- "tianocore-edk2"
- "tianocore-edk2-fatdriver2"
- "tianocore-edk2-basetools"
- The "linaro-tracking" branch is "long lived", it never gets rebased.
- it contains the all latest development work from Linaro
- currently linaro-uefi-2013.01
- The "linaro-release" branch is "long lived", it never gets rebased.
- it contains the latest release from Linaro
- currently linaro-uefi-2013.01
- Monthly tracking branches are created
- At the start of each month, I will update the master branch from
the Tianocore upstreams
- It gets tagged as "linaro-base-YYYY.MM"
- I will then take a branch from this: the monthly tracking branch
- The monthly tracking branch is "long lived", it never gets rebased.
- "linaro-tracking-2013.01" is the most recent branch
- it is now frozen and the release has been cut
- I am about to create the "linaro-tracking-2013.02" branch
- Topic branches are rebased each month
- All branches for specific topics, e.g., Arndale BSP, get rebased to
the monthly tracking branch
- Any upstreamed patches are dropped
- The patch set is tidied up; any "fix" patches are squashed, etc.
- The branch is then merged to the monthly tracking branch
- Release Candidates
- Once all the topic branches are merged to the monthly tracking
branch, tracking gets tagged as a release candidate
- "linaro-tracking" is updated to each RC
- Patches are accepted via the Boot Architecture mailing list
- During the cycle, patches are merged into the relevant topics
- When a complete series of patches is merged, a new RC is created.
- This is currently ad-hoc and not on a time-table
- Each time the tree is updated, a snapshot build is triggered in
Linaro's Continuous Integration system, Jenkins.
- Builds can be found on snapshots.linaro.org [1]
- Release
- At the end of the cycle, the monthly tracking branch is frozen
- Dated follow linux-linaro
- Freeze is the 2nd last Thursday of the month, eg. 21st Feb 2013
- Only urgent fixes can be accepted
- Release Candidate builds are made on the following Monday,
eg. 25th Feb 2013
- The release happens the last Thursday of the month,
eg, 28th Feb 2013
- Release binaries are copied to releases.linaro.org [2]
- The released code is copied to the uefi.git tree [3]
- some users may find a problem using a tree where some branches
are rebased
- uefi.git has only 1 branch and is never rebased
- the SHA ids do not match uefi-next.git
I see this process as "in progress" and open to suggestions and change.
Regards,
Ryan.
[1] https://snapshots.linaro.org/components/kernel/uefi-next
[2] http://releases.linaro.org/13.01/components/kernel/uefi-linaro
[3] http://git.linaro.org/gitweb?p=arm/uefi/uefi.git;a=summary
I am porting the UEFI ARM SctPkg into the core UEFI and I am running into a
problem; Linux Host. The BuildSct.sh is trying to copy a utility called
GenBin_lin{64, 32}, in my case GenBin_lin_64, that should be populated
within ~/SctPkg/Tools/Bin/. My compilation executes fine, but I am unable
to generate a binary because of the lacking GenBin for Linux; there is a
GenBin.exe populated for a Windows Host. Anyone have any advise.
Much appreciated,
Steve
The original message was received at Mon, 28 Jan 2013 19:13:53 +0530 from 140.49.106.138
----- The following addresses had permanent fatal errors -----
boot-architecture(a)lists.linaro.org
The original message was received at Wed, 23 Jan 2013 10:41:34 +0700
from 177.7.60.200
----- The following addresses had permanent fatal errors -----
<boot-architecture(a)lists.linaro.org>
