I looked around a bit and didn't see much chatter about adding an "exclude from build" option to files and folders in a program/library. IMO, when porting code it would be more helpful to do this than #ifdef 0 or delete bsp or hal files that don't pertain to mbed (causing compilation and linking errors).

Just a thought...

+1 to that

+1. Is there a work-around? I really don't want to have to have to maintain two separate branches to support two different build options.

Hi,

Could you give some background to your use case? Why would you want to exclude certain files?

Is this a common feature of other development environments?

Dan

Take for example the case of the USB Host library. It may be desirable to exclude the MSD and the FATfs stuff if you don't need it.

In my case, I have a project (http://mbed.org/users/TickTock/code/CANary/) which had been working great until one of the part suppliers decided to change the way their display worked (http://mbed.org/cookbook/SPI-driven-QVGA-TFT) so new makers are broken. Luckily Peter Drescher kindly provided an updated library(http://mbed.org/users/dreschpe/code/SPI_TFT_ILI9341/) for the new controller so the fix was pretty easy. However, I now have to maintain two separate forks because some customers still have the old displays and mirror all edits into both (old version has to use this library:http://mbed.org/users/dreschpe/code/SPI_TFT/). I would like to collapse this into one project with a compiler directive indicating which version of the display controller a user has and only compile the proper library. I cannot have both of these library included in a project without linker errors.

Thanks guys for your inputs !

@Tick Tock, thanks for clarifying the question u asked recently here in the question thread.

The better solution would be

• Define an abstract class that implement all the common features.
• Define virtual functions within the abstract that must be implemented in child (concrete) class.

Say you have a abstract to display graphics/text on graphical display. You can implement all the functions such as DrawLine(), DrawCircle(), DrawText(), etc. However all this functions need to actually write to the screen using a virtual function DrawPixel().

How can we draw to the 'pixel' depends on the protocol and capability between mbed and the display. You can then implement abstract class such as TFT_Display, Rgb_Led_32x32, etc.

@HM Yoong, that one cannot be applied to all use cases mentioned here. However, agree with a creation of top layer which would define the interface.

@Ashley Mills How would this be done in the online compiler? Ideas?

I consider this option be mostly helpful during the development when not entire implementation is "compile ready" and changes should be tracked (=committed into the revision system), The only approach at the moment is preprocessor macros. Which in case of many files/ entire library, is tedious.

Hi Martin,

With something like the USBHost, I don't think the dependencies such as mbed-rtos should be bundled with it as children. If you think about the way you include libraries in a normal project, all the dependencies are linked separately.

I think it would make more sense if when you import USBHost it would say "Including this library will also require the inclusion of mbed-rtos and FATFileSystem, is this OK?" and then it imports those at the top level rather than as children. This would make more sense, because I often find myself importing something like USBHost into a project that is already using mbed-rtos, so then I have to delete one of the copies of mbed-rtos. It's just not the normal way to nest dependencies when you develop elsewhere.

I understand the ethos behind perhaps bundling these things together so you only have to import "one" thing, but I think the workaround above could be used.

As for how the exclusion could be worked, I think perhaps you could just right click on the folder and mark it as "exclude from build", this would be better than having to delete the folder, because of the implications with syncing the library.

There is actually a very good use case for this which involves setting options for something like USBHost or lwip. It's always a hassle changing the options because if you want to commit your program the old "if you want to commit changes to X you also need to commit changes to Y" comes up, but all you are doing is changing some lwip options. But if you could exclude a file from compilation, you could create your own "options.h" file and leave the one in lwip or whatever untouched.

Another suggestion would be to allow the setting of compilation flags. In many cases there is a debug option, and again if you edit this in the header of the included library, it just causes hassle committing the program, because it wants to commit the changes to the included files. But if this is just a #define, you could pass this in from the compiler.

Ashley

Thanks for all the comments, keep them coming.

I'm thinking there are a number of use cases for this kind of feature, however using this feature is not always the "right" way to do it. So we should provide this, but also provide suggestions and guides for alternative ways of structuring your code.

@tick tock - great use case. In this situation you have really no way to determine which revision of the LCD screen the user has used. Now you could argue it could be possible to detect that but that I assume would be difficult and unreliable. There is no alternative but for the end user to supply some information at build time.

So, the way we are imagining this feature is actually a set of 'configuration options' that your program can present, expressed perhaps in a comment in your top level main.cpp - exactly how is for discussion but it has to be 'part of' your program and versioned, etc.

Perhaps you want to set some defines based on user input, perhaps you want to exclude code, perhaps you want to turn on debug or change compiler flags.

The online IDE would then present those options in a easy to use way.

It could ask the user to for example choose an LCD screen from a drop down list of supported options, and it would remember the choice for subsequent builds. The actual text displayed in the configuration screen would be up to you.

Do you guys have any thoughts on that?

Dan

I think you should make it consistent with typical offline workflows, so if any defines need to be passed, then these should be configurable per compilation unit, and then these would correspond to -D flags in the offline workflow.

Perhaps it means exposing more of the compiler args, or being able to edit the compiler args per compilation unit. I'm not sure.

Ashley

Yep, that is also an important requirement - that it should all be using standard 'non-magic' techniques like that so using it offline is not an issue.

As mbed grows, it would be harder and harder to maintain the standard libraries for different platforms.

I would suggest this

Has a feature availability matrix

• A particular feature from a platform is considered fully supported if it has passed a set of test cases.
• All standard features shall have standard documentation which apply to all platform.
• Hence, we can easily select a platform based on the its hardware cost, HW features, and maturity of its platform-specific library.

Templates/style/library for library

• mbed team has done a good job to create a very good library standard and maintain it.
• In order to encourage new libraries but yet to maintain the standard, some form of guidance and rule-of-thumb shall be documented.
• In the Unix world, all devices could be accessed using open(), close(), write(), read() system calls. All device drivers shall support the low level libraries in order to make the system call available.
• Hence, every one would know what to expect from a library.

Improved automatic documentation generation

• Library dependency shall be included in the source code so that the information could be generated into HTML file.
• The current documentation under the Handbook section is meant for LPC1768. If all the above wishes are available, we could easily obtain
  • Documentation for common API for all platforms.
  • Documentation for platform-specific API