Closed NiklasRosenstein closed 8 years ago
Is this documented? I'm wondering two things. First, it would be nice to automatically include the options without needing to "import *". Secondly, is there a command line flag to specify the config.option file so multiple different option files can be created?
On Sun, May 15, 2016, 8:24 AM Niklas Rosenstein notifications@github.com wrote:
Closed #97 https://github.com/craftr-build/craftr/issues/97 via 1f322c3 https://github.com/craftr-build/craftr/commit/1f322c3ace00b2587cba1965cbf3a93b221c7321 .
— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/craftr-build/craftr/issues/97#event-660991945
The way options are handled is quickly mentioned here: http://craftr.readthedocs.io/en/latest/#target-references-build-options
For now, importing the old craftr.ext.options
module will display a warning until the deprecated module is removed completely.
First, it would be nice to automatically include the options without needing to "import *".
Not sure if I understand you right. I came to the conclusion that any symbols made " built-in" automatically are confusing. I prefer the explicit is better thsn implicit in this case and many others. So instead of having a global options
symbol available by default, the user should import it from the craftr module
from craftr import Framework, path, options # very explicit
from craftr import * # still better than not being required to put this line at all
Secondly, is there a command line flag to specify the config.option file so multiple different option files can be created?
There might be a misunderstanding about options on your side (which might very well drive from the lack of good documentation). I am note sure what you mean by "multiple different option files". Options in Craftr are just environment variables. The craftr.options.get()
function just has some convenient properties compared to reading the option directly using getenv()
or os.environ
.
I want to be able to control what and how things are built based on information provided at build time. For example building for ARM or x86, Linux or windows or bare metal ... that's what I mean.
On Sun, May 15, 2016, 6:44 PM Niklas Rosenstein notifications@github.com wrote:
The way options are handled is quickly mentioned here: http://craftr.readthedocs.io/en/latest/#target-references-build-options
For now, importing the old craftr.ext.options module will display a warning until the deprecated module is removed completely.
First, it would be nice to automatically include the options without needing to "import *".
Not sure if I understand you right. I came to the conclusion that any symbols made " built-in" automatically. I prefer the explicit is better thsn implicit in this case and many others. So instead of having a global options symbol available by default, the user should import it from the craftr module
from craftr import Framework, path, options # very explicit from craftr import * # still better than not being required to put this line at all
Secondly, is there a command line flag to specify the config.option file so multiple different option files can be created?
There might be a misunderstanding about options on your side (which might very well drive from the lack of good documentation). I am note sure what you mean by "multiple different option files". Options in Craftr are just environment variables. The craftr.options.get() function just has some convenient properties compared to reading the option directly using getenv() or os.environ.
— You are receiving this because you commented.
Reply to this email directly or view it on GitHub https://github.com/craftr-build/craftr/issues/97#issuecomment-219332458
Whether you're building for Windows or Linux could be determined from your current operating system. That's in fact whats happening when you import a compiler/link from craftr.ext.platform
.
from craftr.ext.platform import cxx, ld
This will give you GCC on Linux, Clang on Mac and MSVC on Windows. There are some ways to override this behaviour, but if you really want to customize it, you have to do it yourself.
from craftr import *
target = options.get('TargetPlatform')
if target == 'windows':
from craftr.ext.compiler import msvc
cc = msvc.MsvcCompiler('cl', 'c')
ld = msvc.MsvcLinker()
elif target in ('linux', 'arm', 'x86', 'baremetal'):
from craftr.ext import unix
from craftr.ext.compiler import gcc
if target == 'linux':
cc = ld = gcc.GccCompiler('gcc', 'c')
elif target == 'arm':
cc = ld = gcc.GccCompiler('gcc-arm-4.7', 'c')
elif target == 'x86':
cc = ld = gcc.GccCompiler('gcc-x86-4.7', 'c')
else:
cc = ld = gcc.GccCompiler('gcc-baremetal-4.7', 'c')
else:
error('invalid value for TargetPlatform: {!r}'.format(target))
And you'd run Craftr like
craftr -eb -DTargetPlatform=arm
Note that if you're not cross-compiling, the compilers you can import from craftr.ext.platform
read the CC
, CXX
environment variables already so you could just do
CC=gcc-arm-4.7 craftr -eb
, orcraftr -eb -DCC=gcc-arm-4.7
K, txs
On Mon, May 16, 2016 at 5:46 AM Niklas Rosenstein notifications@github.com wrote:
Whether you're building for Windows or Linux could be determined from your current operating system. That's in fact whats happening when you import a compiler/link from craftr.ext.platform.
from craftr.ext.platform import cxx, ld
This will give you GCC on Linux, Clang on Mac and MSVC on Windows. There are some ways to override this behaviour, but if you really want to customize it, you have to do it yourself.
from craftr import * target = options.get('TargetPlatform')if target == 'windows': from craftr.ext.compiler import msvc cc = msvc.MsvcCompiler('cl', 'c') ld = msvc.MsvcLinker()elif target in ('linux', 'arm', 'x86', 'baremetal'): from craftr.ext import unix from craftr.ext.compiler import gcc if target == 'linux': cc = ld = gcc.GccCompiler('gcc', 'c') elif target == 'arm': cc = ld = gcc.GccCompiler('gcc-arm-4.7', 'c') elif target == 'x86': cc = ld = gcc.GccCompiler('gcc-x86-4.7', 'c') else: cc = ld = gcc.GccCompiler('gcc-baremetal-4.7', 'c')else: error('invalid value for TargetPlatform: {!r}'.format(target))
And you'd run Craftr like
craftr -eb -DTargetPlatform=arm
Note that if you're not cross-compiling, the compilers you can import from craftr.ext.platform read the CC, CXX environment variables already so you could just do
- CC=gcc-arm-4.7 craftr -eb, or
- craftr -eb -DCC=gcc-arm-4.7`
— You are receiving this because you commented.
Reply to this email directly or view it on GitHub https://github.com/craftr-build/craftr/issues/97#issuecomment-219416421
Reading configuration values from the environment is a common necessity and should not require importing an additional Craftr extension module. Currently, convenient functions are available in
craftr.ext.options
. This issue proposes moving the module tocraftr.options
and include it incraftr.__all__
so it will be imported automatically withfrom craftr import *
.