SCons usability improvements and GCC support for posix #190

2018-04-05T10:24:03Z

akien-mga commented

2018-04-05 10:24:03 +00:00

(Migrated from github.com)

The first commit uses the SCons Variables object to register (and validate) command line arguments and generate a scons --help output. Using things like BoolVariable makes our life easier as you can specify debug=1, debug=ON, debug=True, debug=yes, etc., basically anything that would make sense for a bool, and it should work.

I tried to keep the arguments names already in use for compatibility, but 64bit is not a valid identifier for SCons options (starts with a number), so I used a string enum bits instead.

That commit also adds support for reading common C and C++ configuration flags from the environment and/or the command line. Those are used by the second commit to remove the hardcoded CXX=clang++ on Linux and let the user define it.

Fixes #184.

Note that GCC builds doesn't work out of the box for me with GCC 5.5.0. #189 is needed to fix a first compilation, and then I hit a second one for which I'll open a ticket (Edit: #191).

The first commit uses the SCons `Variables` object to register (and validate) command line arguments and generate a `scons --help` output. Using things like `BoolVariable` makes our life easier as you can specify `debug=1`, `debug=ON`, `debug=True`, `debug=yes`, etc., basically anything that would make sense for a bool, and it should work. I tried to keep the arguments names already in use for compatibility, but `64bit` is not a valid identifier for SCons options (starts with a number), so I used a string enum `bits` instead. That commit also adds support for reading common C and C++ configuration flags from the environment and/or the command line. Those are used by the second commit to remove the hardcoded `CXX=clang++` on Linux and let the user define it. Fixes #184. ---- Note that GCC builds doesn't work out of the box for me with GCC 5.5.0. #189 is needed to fix a first compilation, and then I hit a second one for which I'll open a ticket (*Edit:* #191).

akien-mga commented

2018-04-05 10:27:54 +00:00

(Migrated from github.com)

Are Travis CI builds disabled for PRs? That's where they are most useful IMO, it would be nice to have them in this case to confirm that it still builds fine on CI before merging.

CelticMinstrel commented

2018-04-05 13:14:09 +00:00

(Migrated from github.com)

I don't remember if or why they were disabled, but I can look into enabling Travis builds for this PR.

CelticMinstrel commented

2018-04-07 00:57:00 +00:00

(Migrated from github.com)

I just enabled PR builds on Travis, but I think you'll need to push something new before it notices this.

akien-mga commented

2018-04-07 10:18:16 +00:00

(Migrated from github.com)

I'll take the opportunity to add a GCC build to Travis then :)

akien-mga commented

2018-04-07 14:18:49 +00:00

(Migrated from github.com)

Should be good to merge now, both GCC and Clang builds work fine on Travis (and locally) for Linux.

The OSX builds seem to still work, though they still fail with that spurious Resource temporarily unavailable error. It might be worth giving it a try locally once to ensure that OSX builds still work for you after the SCons changes.

Should be good to merge now, both GCC and Clang builds work fine on Travis (and locally) for Linux. The OSX builds seem to still work, though they still fail with that spurious `Resource temporarily unavailable` error. It might be worth giving it a try locally once to ensure that OSX builds still work for you after the SCons changes.

CelticMinstrel commented

2018-04-07 17:18:00 +00:00

(Migrated from github.com)

Apart from one test failure (segfault), this works with scons on my Mac.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: openboe/oboe#190