I need to copy org.apache.commons.net.ftp.FTPSClient and org.springframework.integration.ftp.session.DefaultFtpsSessionFactory, and refine some methods, What should I note in this case?
For example, do I need to copy the copyright? And is there anything else need attention?
Take a look at Apache License 2.0 . Under section 4 it's clearly defined what you have to do when you want to redistribute (changed) code.
You must give any other recipients of the Work or Derivative Works a copy of this License; and
You must cause any modified files to carry prominent notices stating that You changed the files; and
Include the Apache License 2.0 to your work and add to the changed file that you have changed it.
You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; and
Don't remove existing copyright, patent, trademarks and attribution notices.
If the Work includes a "NOTICE" text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear. The contents of the NOTICE file are for informational purposes only and do not modify the License. You may add Your own attribution notices within Derivative Works that You distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such additional attribution notices cannot be construed as modifying the License.
If the original work contains a NOTICE file you have to include a copy of it in your changed work.
If you follow these instructions you can modify code which is distributed under the Apache License as you pleased and distribute your work under every license you want without noticing anybody.
Related
I would like to check for the presence of a valid license header in our Java source code using the com.mycila:license-maven-plugin
The issue is currently that most files contain additional text - besides the license - in the initial comment. Several programmers obviously added the class' name (plus an empty line) before the license (maybe that was also done automatically by an earlier IDE), others added additional details about the class after the license header.
Since I don't want to omit that extra text I am seeking for a possibility or option to check for the presence of the exact license header content but allow at least for additional leading text (which should be ignored otherwise).
The cases which contain additional text after the license are not too frequent, so here I could imagine to manually split those into two comments.
It would be great if the plugin would only check that the license header is contained in the first comment, not that the first comment it is completely identical to the predefined header.
Is that feasible?
Considering all freedom that yocto gives to the developer, I have a question.
I would like to make this my_file.inc available only for recipes in one particular meta-layer. I know, that, for instance, using INHERIT keyword inside the local.conf will make my_class.bbclass file available globally for each recipe.
Is it a good practice to add this:
require my_file.inc
inside layer.conf? Or should I change my_file.inc to the my_file.bbclass, and, add INHERIT = "my_file.bbclass" to the layer.conf?
Any other possibilities?
Even if it seems to work, neither of your approaches is technically completely correct. The key point is that all .conf files are parsed first and everything they contain is globally visible throughout the whole build process. So if you add something through the layer.conf file, itis not being pulled in through an unexpected place, it also is not being limited that layer only and might therefore cause breakage at other places.
While I do not have a really good and clean solution, maybe the following can help you:
You can make your custom recipes react on certain keywords in DISTRO_FEATURES or MACHINE_FEATURES. Then you can create a two-staged approach:
Add the desired keyword in local.conf (or your MACHINE, or DISTRO, or whatever configuration)
Make the recipes react to it. If you need the mechanism in several places, then it might be useful to pour it into a .bbclass that your layer brings along and that you pull in for the respective recipes.
This way the effect is properly contained.
Maybe part 5.1.3.2 from the Yocto Project answers your question:
Avoid duplicating include files. Use append files (.bbappend) for each recipe that uses an include file. Or, if you are introducing a new recipe that requires the included file, use the path relative to the original layer directory to refer to the file. For example, use require recipes-core/package/file.inc instead of require file.inc. If you're finding you have to overlay the include file, it could indicate a deficiency in the include file in the layer to which it originally belongs. If this is the case, you should try to address that deficiency instead of overlaying the include file. For example, you could address this by getting the maintainer of the include file to add a variable or variables to make it easy to override the parts needing to be overridden.
So to avoid duplicate inclusion later, it would be better not to include your .inc file(s) this way.
I will keep it short. I have been handed a yocto repository and asked to audit it for the licences used by the build. My end goal is to:
List all the licenses used by the distro (i.e. licenses used by all the tools and utilities built with distro)
Get a copy of the license file
Get the URL on the internet, where that licence text can be found. (if someone else wants to compare it with what I have provided them)
Being a lazy "software engineer" I am, I want to avoid doing this task and just parse all the .bb files to extract all that information.
I have seen some recipes, which include headers, which in turn have the license information. It'd be nice to be able to follow the trail.
This project on GitHub looks promising. But might not get me exactly what I need.
I also have the entire source code and the license file text distributed with the source code. I should be able to write a simple script to achieve this, but the text in some licenses don't contain the type of license itself.
Any pointers will be greatly appreciated.
First of all, you probably want licenses used in your image, not distro, as you can build all kinds of recipes within any distro, so what matters is only what you ship, which is your image. The way to find out licenses used by software in an image is already described here, but your question differentiates a bit in that you also want full license texts. That's also easy, it's all there in per-package directories in build/tmp/deploy/licenses.
As for your third subquestion, it's not that easy because even something standard like GPLv2 has little variations from project to project, some have exceptions, some have "(c) $YEARS" written in different way, so what the Openembedded build system gives you is actually more reliable as it's extracted from the source. What is possible is to provide the source code itself (via archiver class) along with license information, anyone really curious could cross-check sources and licenses that way.
You should be able to address 1) and 2) via https://www.yoctoproject.org/docs/1.8/dev-manual/dev-manual.html#maintaining-open-source-license-compliance-during-your-products-lifecycle .
Xcode has a habit of putting all kinds of (redundant) information at the top of each code file it creates, containing copyright notices, class names, project names and client names. Like it or not, once you create a new class "A", then refactor it to be called "B", the information is wrong already. The comments will keep saying that this is "A.h" or "A.m". In addition, if you reuse classes from one project in a next, it will also state the wrong project name.
//
// A.h
// ProjectName
//
// Created by Author on 19-06-11.
// Copyright 2011 CompanyName. All rights reserved.
//
There must be a reason there aren't many people complaining about this. What is your trick to keep the header comments up to date? Is there a tool that auto-corrects it all? Is there a hidden setting?
Cheers,
EP.
There may be a way to update your comments but it will be tricky.
As far a customizing the template, this is not as bad. it is just a text file located in
/Developer/Platforms/iPhoneOS.platform/Developer/Library/Xcode/Templates/File Templates/Cocoa Touch/
Don't edit the files here, they will get overwritten when you update, or reinstall xcode.
Place your custom templates here, in your home directory.
~/Library/Developer/Xcode/Templates/File Templates/
High Order Bit explains further.
Short Answer: Use SCM Commit Hooks (git example, svn example, cvs example)
Reason: Well, you can be rest assured that XCode will not do it. What XCode can do is attach itself to version control system. Its fairly simple to do using commit hooks that most SCMs support. They fire up before/after the commit/push so that source code is updated. You can even send automated emails when commiting etc.
Since GIT is the most popular one in my opinion these days, see this article.
I use custom templates (see #TMB's comment for a link explaining creating your own) that eliminate the project name and copyright info. File name changes rarely enough that that hasn't bothered me yet. If it became a problem, I would just eliminate it from my templates. If I did it again, I would eliminate the file line from the start: There are better and more reliable ways to figure out what file you're in than going to the top of the file.
I'm producing a hex file to run on an ARM processor which I want to keep below 32K. It's currently a lot larger than that and I wondered if someone might have some advice on what's the best approach to slim it down?
Here's what I've done so far
So I've run 'size' on it to determine how big the hex file is.
Then 'size' again to see how big each of the object files are that link to create the hex files. It seems the majority of the size comes from external libraries.
Then I used 'readelf' to see which functions take up the most memory.
I searched through the code to see if I could eliminate calls to those functions.
Here's where I get stuck, there's some functions which I don't call directly (e.g. _vfprintf) and I can't find what calls it so I can remove the call (as I think I don't need it).
So what are the next steps?
Response to answers:
As I can see there are functions being called which take up a lot of memory. I cannot however find what is calling it.
I want to omit those functions (if possible) but I can't find what's calling them! Could be called from any number of library functions I guess.
The linker is working as desired, I think, it only includes the relevant library files. How do you know if only the relevant functions are being included? Can you set a flag or something for that?
I'm using GCC
General list:
Make sure that you have the compiler and linker debug options disabled
Compile and link with all size options turned on (-Os in gcc)
Run strip on the executable
Generate a map file and check your function sizes. You can either get your linker to generate your map file (-M when using ld), or you can use objdump on the final executable (note that this will only work on an unstripped executable!) This won't actually fix the problem, but it will let you know of the worst offenders.
Use nm to investigate the symbols that are called from each of your object files. This should help in finding who's calling functions that you don't want called.
In the original question was a sub-question about including only relevant functions. gcc will include all functions within every object file that is used. To put that another way, if you have an object file that contains 10 functions, all 10 functions are included in your executable even if one 1 is actually called.
The standard libraries (eg. libc) will split functions into many separate object files, which are then archived. The executable is then linked against the archive.
By splitting into many object files the linker is able to include only the functions that are actually called. (this assumes that you're statically linking)
There is no reason why you can't do the same trick. Of course, you could argue that if the functions aren't called the you can probably remove them yourself.
If you're statically linking against other libraries you can run the tools listed above over them too to make sure that they're following similar rules.
Another optimization that might save you work is -ffunction-sections, -Wl,--gc-sections, assuming you're using GCC. A good toolchain will not need to be told that, though.
Explanation: GNU ld links sections, and GCC emits one section per translation unit unless you tell it otherwise. But in C++, the nodes in the dependecy graph are objects and functions.
On deeply embedded projects I always try to avoid using any standard library functions. Even simple functions like "strtol()" blow up the binary size. If possible just simply avoid those calls.
In most deeply embedded projects you don't need a versatile "printf()" or dynamic memory allocation (many controllers have 32kb or less RAM).
Instead of just using "printf()" I use a very simple custom "printf()", this function can only print numbers in hexadecimal or decimal format not more. Most data structures are preallocated at compile time.
Andrew EdgeCombe has a great list, but if you really want to scrape every last byte, sstrip is a good tool that is missing from the list and and can shave off a few more kB.
For example, when run on strip itself, it can shave off ~2kB.
From an old README (see the comments at the top of this indirect source file):
sstrip is a small utility that removes the contents at the end of an
ELF file that are not part of the program's memory image.
Most ELF executables are built with both a program header table and a
section header table. However, only the former is required in order
for the OS to load, link and execute a program. sstrip attempts to
extract the ELF header, the program header table, and its contents,
leaving everything else in the bit bucket. It can only remove parts of
the file that occur at the end, after the parts to be saved. However,
this almost always includes the section header table, and occasionally
a few random sections that are not used when running a program.
Note that due to some of the information that it removes, a sstrip'd executable is rumoured to have issues with some tools. This is discussed more in the comments of the source.
Also... for an entertaining/crazy read on how to make the smallest possible executable, this article is worth a read.
Just to double-check and document for future reference, but do you use Thumb instructions? They're 16 bit versions of the normal instructions. Sometimes you might need 2 16 bit instructions, so it won't save 50% in code space.
A decent linker should take just the functions needed. However, you might need compiler & linke settings to package functions for individual linking.
Ok so in the end I just reduced the project to it's simplest form, then slowly added files one by one until the function that I wanted to remove appeared in the 'readelf' file. Then when I had the file I commented everything out and slowly add things back in until the function popped up again. So in the end I found out what called it and removed all those calls...Now it works as desired...sweet!
Must be a better way to do it though.
To answer this specific need:
•I want to omit those functions (if possible) but I can't find what's
calling them!! Could be called from any number of library functions I
guess.
If you want to analyze your code base to see who calls what, by whom a given function is being called and things like that, there is a great tool out there called "Understand C" provided by SciTools.
https://scitools.com/
I have used it very often in the past to perform static code analysis. It can really help to determine library dependency tree. It allows to easily browse up and down the calling tree among other things.
They provide a limited time evaluation, then you must purchase a license.
You could look at something like executable compression.