[Scons-users] Advice sought
Dominic Binks
dominic.binks at thebinkles.net
Sun Feb 8 16:23:26 EST 2015
So to be more concrete again :)
We support about 8 or 9 (currently) different embedded platforms which
fall into two camps. Most are linux based embedded systems and so are
pretty similar to a PC based system. The others are RTOS based
platforms which are incapable to supporting executables in the general
sense.
The software that runs on these devices does a kind of template
matching. On the PC side there are tools for generating the template
data. These tools will only ever run on the PC side.
We have a message specification similar to IDL or protocol buffers but
lighter weight and sufficient for our relatively simple needs.
A python script reads the specification and produces a .c and .h for the
serialization/deserialization routines for the messages.
There is also a hardware abstraction layer to deal with variations
between the platforms (windows, linux and RTOS platforms). This is
predominantly used in builds that go to the embedded devices. Because
the serialization/deserialization code goes to the embedded platforms we
use it there which also means that some host code also needs to use as
even though it doesn't strictly need it.
The serialization code provides a mechanism for tools on the PC side to
talk to the embedded device and extract information and change what it
does etc.
So we have the following bits of code that need to be compiled:
- platform abstraction layer - needs to be compiled for PC and embedded
platforms to run on both
- message serialization code - needs to be compiled for PC and embedded
platforms to run on both
- template matching code - needs to be compiled for embedded platforms
only to run on embedded only
- template generation code - needs to be compiled for host platforms
only to run on PC only
- test tools and code - currently compiled only for host, but could be
target as well for platforms that are capable of supporting it.
While the sources are fairly separate they are not completely separated
and it would be less clear to separate them out.
Hope this helps to understand what I'm trying to achieve.
Dominic
On 08/02/2015 20:26, Bill Deegan wrote:
> Dominic,
>
> So to simpify
> 1) You need to build a tool only on the host
> 2) you need this tool to be run only on the host
> 3) This tool generates source files which need to be built on both host
> and target
> 4) ? these files are compiled into tools on both host and target?
>
> -Bill
>
> On Sun, Feb 8, 2015 at 11:28 AM, Dominic Binks
> <dominic.binks at thebinkles.net <mailto:dominic.binks at thebinkles.net>> wrote:
>
> Sure.
>
> The file builds probably 200 files. We use a couple of third party
> libraries which contribute most of this count. I estimate about
> half will go to target, approximately half to host, and probably 10%
> that will go to both.
>
> VariantDirs may solve my problem, but I've not yet had a feel for
> how to make them work for it. I had thought to do something like
> that but from what I've read on the wiki, to use VariantDir you need
> to map the source files to the variant.
>
> To be a little more specific to help you understand the current
> problem I'm facing we have a tool to help us understand what our
> code is doing on device. This involves a simpole serialization
> protocol to support the exchange of data of our own design which
> produces a .c and .h that needs to be compiled for both target and
> host. The tool itself is compiled for the host.
>
> There are also data preparation tools that only run on the host.
> And a tool which can be used for testing which, if the target
> supports executables, can be compiled for both host and target.
>
> Currently the introspection tool does not build for Android. It's
> possible I could fix that but it doesn't actually need to run on
> Android, only on a windows or linux/x86 host so there's not really
> much point in fixing.
>
> If you think VariantDirs can support what I need to do, I wonder if
> you'd be able to provide some kind of example I can study (or recast
> my current solution) and I can then see if VariantDirs will solve
> the problem.
>
> I'm not resisting making big changes to the build system but I would
> like to develop it so that it's easy to understand and maintain for
> the other developers on the team, if that means more work me, that's
> fine so long as I can get to a clear solution.
>
> Thanks for your help.
> Dominic
>
>
> On 08/02/2015 13:26, Dirk Baechle wrote:
>
> Hi Dominic,
>
> Am 07.02.2015 um 22:16 schrieb Dominic Binks:
>
> Hi all,
>
> I'm looking for some expert advice on how to go about
> implementing
> (well technically modifying) a build system to achieve a
> separated host and target build output.
>
> [...]
>
> The Android build system which is based on make has quite a
> clean way
> of doing this. I imagined that VariantDir() would help me out
> here but reading more about it, it doesn't really do what I
> need.
>
> can you be a little bit more specific about why VariantDirs aren't a
> valid solution for you? It would also be interesting to know
> about how
> many targets and source files we are talking about here (in rough
> numbers). Are all source files compileable for both targets, so
> could
> one possibly use VariantDirs to compile the basic Objects...and
> then, in
> a separate SConscript, collect them together into the final
> executables
> as needed for each target system?
>
> My first impression is that a good answer can only be given in
> relation
> to your current build structure, so a few more infos would be
> helpful.
>
> Best regards,
>
> Dirk
>
> _________________________________________________
> Scons-users mailing list
> Scons-users at scons.org <mailto:Scons-users at scons.org>
> https://pairlist4.pair.net/__mailman/listinfo/scons-users
> <https://pairlist4.pair.net/mailman/listinfo/scons-users>
>
> _________________________________________________
> Scons-users mailing list
> Scons-users at scons.org <mailto:Scons-users at scons.org>
> https://pairlist4.pair.net/__mailman/listinfo/scons-users
> <https://pairlist4.pair.net/mailman/listinfo/scons-users>
>
>
More information about the Scons-users
mailing list