Portable Build Environment

Question

I am trying to figure out how define my build environment.

I have multiple reusable standalone modules that are developed on their own release schedules.
I also have multiple customers that each have their own custom built application using different revisions of each reusable module.
I am using g++/makefiles for my build system
I need to make it portable for Cygwin and Linux.
1. Assuming each module/customer is built with its own Makefile, How can I configure my makefiles to dynamically point to the correct version of dependency?
2. How could/should I setup my CM repo to allow the development teams for each project and module to work independently and not have to lots of manual configuration each time they create a new branch?

I am using the following directory structure, but it doesnt seem sufficient for my needs.

./fooLibrary
    ./include
    ./lib 
./barLibrary
    ./include
    ./lib 
./plugins
    ./pluginX
        ./include
        ./lib 
    ./pluginY
        ./include
        ./lib 
    ./pluginZ
        ./include
        ./lib 
./projects
    ./customer1
        ./bin
        ./obj       
./projects/customer2
        ./bin
        ./obj       
./projects/unittests
        ./bin
        ./obj

I was toying with creating a versioned install directory for each module with their own include/lib directories, but that seems overkill, and I never really liked versioning products of builds. i.e.

    ./fooLibrary
        ./src
        ./1.0
            ./include
            ./lib 
        ./1.1
            ./include
            ./lib 
        ./1.2
            ./include
            ./lib 
        ./1.2.1
            ./include
            ./lib

I'm just trying to keep it simple for the development team.

EDIT: Its important to note that I dont have anything working yet. I feel like I am trying to do something right, but I am thrashing while trying to get it right.

You're on a good way, using GNU `make` natively, that should serve you well fo cygwin based systems and MinGw based on windows machines. Though your question is too broad. The approach we're using at our company is to `include` `config.mk` files from certain levels in the directory structure, and have make template functions for certain targets. It's much too broad to explain here exactly how it works, despite that would disclose some proprietary company intelligence. — πάντα ῥεῖ, Jul 06 '15 at 19:31
_@Jerunh_ If you're using a decent IDE (e.g. like Eclipse CDT), you may start out with the Makefile's generated by these. — πάντα ῥεῖ, Jul 06 '15 at 19:35
All platform-independent build systems suck. That's why [this list](https://en.wikipedia.org/wiki/List_of_build_automation_software) is so long... If you do a lot on Linux, I would say it's in your best interest to learn autotools as it's most common. Not necessary "best", just most common. — Brian McFarland, Jul 06 '15 at 20:37

score 1 · Answer 1 · answered Jul 06 '15 at 19:31

Regarding the CM part, if you're using GIT you can have one master repository for the top directory and the base build system, and submodules for each sub-project.

As for building, I suggest you make each sub-project stand-alone, then have a list of the sub-projects in the top-level container project in dependency order. Each sub-project installs into one specific directory, and the top-level container-project passes flags to each project telling them the location of this installation directory so they can find header files and libraries. Make this (temporary) installation directory mirror the actual installation directory, so it's easy to copy to the actual installation directory when needed.

If not all files should be copied from the temporary installation directory to the actual installation directory, have each sub-project generate a file which tells which files should be copied.

For platform-independent build system I suggest CMake. It can handle both configuration and generating makefiles for building, for more platforms and compilers than you probably will need.

I hope any of this makes sense to you.

I seriously have to disagree about recommending _`CMake`_. There were a number of issues I wasn't able to fix using CMake, while using `make` natively it was easy to solve (Not saying, that it was easy to setup the basic templates and rules). I rarely disagree with you, ya should know. — πάντα ῥεῖ, Jul 06 '15 at 19:38
@πάντα ῥεῖ I was reading up on 'CMake' and it seems like the portable solution I'm looking for. Could you elaborate further on the issues that you couldnt resolve? — Jerunh, Jul 06 '15 at 22:15
@Jerunh E.g. simple stuff like grouping libraries with the linker options: [`-Wl,--start-group -lmy_lib -lyour_lib -lhis_lib -Wl,--end-group`](http://stackoverflow.com/questions/5651869/gcc-what-are-the-start-group-and-end-group-command-line-options). — πάντα ῥεῖ, Jul 06 '15 at 22:24

Portable Build Environment

1 Answers1