craftr-build / craftr-build-4.x

Frontend for the Craftr build framework.
https://craftr-build.github.io/craftr/
Other
60 stars 14 forks source link

Move options extension module to Craftr main module #97

Closed NiklasRosenstein closed 8 years ago

NiklasRosenstein commented 8 years ago

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 to craftr.options and include it in craftr.__all__ so it will be imported automatically with from craftr import *.

winksaville commented 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

NiklasRosenstein commented 8 years ago

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.

winksaville commented 8 years ago

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

NiklasRosenstein commented 8 years ago

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

winksaville commented 8 years ago

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