[jira] [Commented] (MYNEWT-353) BLE Host - Timeout for ATT queued writes

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYNEWT-353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15713793#comment-15713793
 ] 

ASF subversion and git services commented on MYNEWT-353:


Commit 198143989112b3b55f1d50619c938e3b34fc63f9 in incubator-mynewt-core's 
branch refs/heads/develop from [~ccollins476]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-mynewt-core.git;h=1981439 
]

MYNEWT-353 BLE Host - Timeout for ATT queued write

If a queued write is only partially received, and 30 seconds has passed
since the last prepare write was received, a timeout occurs.  When this
happens, the connection is terminated.


> BLE Host - Timeout for ATT queued writes
> 
>
> Key: MYNEWT-353
> URL: https://issues.apache.org/jira/browse/MYNEWT-353
> Project: Mynewt
>  Issue Type: Improvement
>  Components: Nimble
>Reporter: Christopher Collins
>Assignee: Christopher Collins
> Fix For: v1_0_0_rel
>
>
> A peer performs a large attribute write by sending a series of ATT prepare 
> write requests followed by an ATT execute write request.  If the execute 
> write request never arrives, the queued prepare write requests remain 
> resident on the receiving device.  The queued write should be cleared N 
> seconds after the last received prepare write request.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (MYNEWT-353) BLE Host - Timeout for ATT queued writes

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins resolved MYNEWT-353.

Resolution: Fixed

> BLE Host - Timeout for ATT queued writes
> 
>
> Key: MYNEWT-353
> URL: https://issues.apache.org/jira/browse/MYNEWT-353
> Project: Mynewt
>  Issue Type: Improvement
>  Components: Nimble
>Reporter: Christopher Collins
>Assignee: Christopher Collins
> Fix For: v1_0_0_rel
>
>
> A peer performs a large attribute write by sending a series of ATT prepare 
> write requests followed by an ATT execute write request.  If the execute 
> write request never arrives, the queued prepare write requests remain 
> resident on the receiving device.  The queued write should be cleared N 
> seconds after the last received prepare write request.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (MYNEWT-341) BLE Host - Handle missing ACL data fragments

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins resolved MYNEWT-341.

Resolution: Fixed

> BLE Host - Handle missing ACL data fragments
> 
>
> Key: MYNEWT-341
> URL: https://issues.apache.org/jira/browse/MYNEWT-341
> Project: Mynewt
>  Issue Type: Improvement
>Reporter: Christopher Collins
>Assignee: Christopher Collins
> Fix For: v1_0_0_rel
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MYNEWT-341) BLE Host - Handle missing ACL data fragments

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYNEWT-341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15713559#comment-15713559
 ] 

ASF subversion and git services commented on MYNEWT-341:


Commit 0d402e54aa6d0fa24f31eebac15038b1d00b969b in incubator-mynewt-core's 
branch refs/heads/develop from [~ccollins476]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-mynewt-core.git;h=0d402e5 
]

MYNEWT-341 BLE Host - Handle missing ACL fragments

If a packet is only partially received, and 30 seconds has passed since
the last fragment was received, a timeout occurs.  When this happens,
the connection is terminated.


> BLE Host - Handle missing ACL data fragments
> 
>
> Key: MYNEWT-341
> URL: https://issues.apache.org/jira/browse/MYNEWT-341
> Project: Mynewt
>  Issue Type: Improvement
>Reporter: Christopher Collins
>Assignee: Christopher Collins
> Fix For: v1_0_0_rel
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (MYNEWT-500) newt - Ambiguity when package contains two source files with the same filename

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins resolved MYNEWT-500.

Resolution: Fixed

> newt - Ambiguity when package contains two source files with the same filename
> --
>
> Key: MYNEWT-500
> URL: https://issues.apache.org/jira/browse/MYNEWT-500
> Project: Mynewt
>  Issue Type: Bug
>  Components: Newt
>Reporter: Christopher Collins
>Assignee: Christopher Collins
> Fix For: v1_0_0_rel
>
>
> For example, the arduino repo (until very recently) contained the following 
> two files:
> * 
> {{hw/mcu/atmel/samd21xx/src/sam0/utils/cmsis/samd21/source/gcc/startup_samd21.c}}
> * {{hw/mcu/atmel/samd21xx/src/startup_samd21.c}}
> Both of these files are in the same package (hw/mcu/atmel/samd21) and they 
> both have the same filename (startup_samd21c).
> During a build, newt compiles both, but only links in one object file.
> The problem is that the bin directory structure does not mirror that of the 
> source tree.  Specifically, all of a package's object files get put in the 
> same directory; subtrees are not preserved.  Consequently, the second .o file 
> overwrites the first.
> The fix is to preserve the source directory structure in the bin directory.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MYNEWT-500) newt - Ambiguity when package contains two source files with the same filename

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYNEWT-500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15713489#comment-15713489
 ] 

ASF subversion and git services commented on MYNEWT-500:


Commit 46103ff05fa4c639f64e68fd47ac89a3de3b90e1 in incubator-mynewt-newt's 
branch refs/heads/develop from [~ccollins476]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-mynewt-newt.git;h=46103ff 
]

MYNEWT-500 newt - preserve src dir tree in bin dir

This addresses an ambiguity that occurs when a package contains two
source files with the same filename.  For example, the arduino repo
(until very recently) contained the following two files:


hw/mcu/atmel/samd21xx/src/sam0/utils/cmsis/samd21/source/gcc/startup_samd21.c
hw/mcu/atmel/samd21xx/src/startup_samd21.c

Both of these files are in the same package (hw/mcu/atmel/samd21) and
they both have the same filename (startup_samd21c).

During a build, newt compiles both, but only links in one object file.

The problem is that the bin directory structure does not mirror that of
the source tree. Specifically, all of a package's object files get put
in the same directory; subtrees are not preserved. Consequently, the
second .o file overwrites the first.

The fix is to preserve the source directory structure in the bin
directory.


> newt - Ambiguity when package contains two source files with the same filename
> --
>
> Key: MYNEWT-500
> URL: https://issues.apache.org/jira/browse/MYNEWT-500
> Project: Mynewt
>  Issue Type: Bug
>  Components: Newt
>Reporter: Christopher Collins
>Assignee: Christopher Collins
> Fix For: v1_0_0_rel
>
>
> For example, the arduino repo (until very recently) contained the following 
> two files:
> * 
> {{hw/mcu/atmel/samd21xx/src/sam0/utils/cmsis/samd21/source/gcc/startup_samd21.c}}
> * {{hw/mcu/atmel/samd21xx/src/startup_samd21.c}}
> Both of these files are in the same package (hw/mcu/atmel/samd21) and they 
> both have the same filename (startup_samd21c).
> During a build, newt compiles both, but only links in one object file.
> The problem is that the bin directory structure does not mirror that of the 
> source tree.  Specifically, all of a package's object files get put in the 
> same directory; subtrees are not preserved.  Consequently, the second .o file 
> overwrites the first.
> The fix is to preserve the source directory structure in the bin directory.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MYNEWT-500) newt - Ambiguity when package contains two source files with the same filename

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-500:
--

 Summary: newt - Ambiguity when package contains two source files 
with the same filename
 Key: MYNEWT-500
 URL: https://issues.apache.org/jira/browse/MYNEWT-500
 Project: Mynewt
  Issue Type: Bug
  Components: Newt
Reporter: Christopher Collins
Assignee: Christopher Collins
 Fix For: v1_0_0_rel


For example, the arduino repo (until very recently) contained the following two 
files:

* 
{{hw/mcu/atmel/samd21xx/src/sam0/utils/cmsis/samd21/source/gcc/startup_samd21.c}}
* {{hw/mcu/atmel/samd21xx/src/startup_samd21.c}}

Both of these files are in the same package (hw/mcu/atmel/samd21) and they both 
have the same filename (startup_samd21c).

During a build, newt compiles both, but only links in one object file.

The problem is that the bin directory structure does not mirror that of the 
source tree.  Specifically, all of a package's object files get put in the same 
directory; subtrees are not preserved.  Consequently, the second .o file 
overwrites the first.

The fix is to preserve the source directory structure in the bin directory.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (MYNEWT-496) Update www.apache.org/licenses/exports/ with tinycrypt and polarssl info

[Justin Mclean (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Mclean resolved MYNEWT-496.
--
Resolution: Fixed

Changes made but not published live as there are other pending changes.

> Update  www.apache.org/licenses/exports/ with tinycrypt and polarssl info
> -
>
> Key: MYNEWT-496
> URL: https://issues.apache.org/jira/browse/MYNEWT-496
> Project: Mynewt
>  Issue Type: Task
>Affects Versions: v1_0_0_beta1
>Reporter: Aditi Hilbert
>Assignee: Justin Mclean
> Fix For: v1_0_0_beta1
>
>
> 1. Update www.apache.org/licenses/exports/ with Apache Mynewt crypto info
> (we have added polarssl and tinycrypt.
> 2. Send email to US govt. notifying our crypto code cryptography qualifies 
> for the TSU exception
> (the repo link has changed since last filing)
> 3. We also have to place the notice below in each distribution's README file:
> ` This distribution includes cryptographic software. The country in which you 
> currently reside may have restrictions on the import, possession, use, and/or 
> re-export to another country, of encryption software. BEFORE using any 
> encryption software, please check your country's laws, regulations and 
> policies concerning the import, possession, or use, and re-export of 
> encryption software, to see if this is permitted. See 
>  for more information.
> The U.S. Government Department of Commerce, Bureau of Industry and Security 
> (BIS), has classified this software as Export Commodity Control Number (ECCN) 
> 5D002.C.1, which includes information security software using or performing 
> cryptographic functions with asymmetric algorithms. The form and manner of 
> this Apache Software Foundation distribution makes it eligible for export 
> under the License Exception ENC Technology Software Unrestricted (TSU) 
> exception (see the BIS Export Administration Regulations, Section 740.13) for 
> both object code and source code.
> The following provides more details on the included cryptographic software: 
> ... `  components of the release including cryptography.>
> needs to be fixed before release candidate is put to vote.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (MYNEWT-365) newt can't handle files with spaces

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins resolved MYNEWT-365.

Resolution: Fixed

Thanks Tim.  I agree with everything you said.  There really was no reason we 
were using the shell to execute external commands other than convenience.

I have pushed a fix for this ticket.  Now newt uses the Go exec package to 
execute external commands.

> newt can't handle files with spaces
> ---
>
> Key: MYNEWT-365
> URL: https://issues.apache.org/jira/browse/MYNEWT-365
> Project: Mynewt
>  Issue Type: Bug
>  Components: Newt
>Affects Versions: v0_9_0
> Environment: Any
>Reporter: Tim
>Assignee: Christopher Collins
>Priority: Minor
>
> I was just looking at the code that decides where gcc is run from (so I can 
> see if I can make it always run from /workspace, so full paths are used), 
> when I noticed you don't handle program arguments properly.
> See [this 
> code|https://github.com/apache/incubator-mynewt-newt/blob/8abc4f2c2bb1ab784a854cdf5662e79d88a41407/newt/toolchain/compiler.go#L262]
> {code}
>   cmd += " -c " + "-o " + objPath + " " + file +
>   " " + c.cflagsString() + " " + c.includesString()
> {code}
> Command line arguments should be stored as a {{[]string}} instead of a 
> space-delimited {{string}}. Then you don't need to worry about spaces or 
> escaping or anything like that. In other words something like this:
> {code}
> func (c *Compiler) CompileFileCmd(file string,
>   compilerType int) ([]string, error) {
>   objFile := strings.TrimSuffix(file, filepath.Ext(file)) + ".o"
>   objPath := filepath.ToSlash(c.dstDir + "/" + objFile)
>   cmd := make([]string)
>   switch compilerType {
>   case COMPILER_TYPE_C:
>   cmd = cmd.append(c.ccPath)
>   case COMPILER_TYPE_ASM:
>   cmd = cmd.append(c.asPath)
>   default:
>   return nil, util.NewNewtError("Unknown compiler type")
>   }
>   cmd = append(cmd, "-c", "-o", objPath, file)
>   // There will be some special handling for these, depending on what 
> they contain (I'm not sure of the format of these exactly).
> //c.cflagsString(), c.includesString()
>   return cmd, nil
> }
> {code}
> And then don't use ShellCommand() to run it. Is there any reason that you're 
> using {{sh -c}} rather than just running the command directly? It's going to 
> make porting to Windows a pain. Similarly for code like this:
> {code}
> func CopyFile(srcFile string, destFile string) error {
>   _, err := ShellCommand(fmt.Sprintf("mkdir -p %s", 
> filepath.Dir(destFile)))
>   if err != nil {
>   return err
>   }
>   if _, err := ShellCommand(fmt.Sprintf("cp -Rf %s %s", srcFile,
>   destFile)); err != nil {
>   return err
>   }
>   return nil
> }
> {code}
> That won't work on Windows and also won't work with files containing spaces. 
> Better to use Go's proper functions for creating directories and copying 
> files. (Unfortunately there isn't a built-in equivalent of {{cp -Rf}} but if 
> you google it there is lots of example code.)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MYNEWT-365) newt can't handle files with spaces

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYNEWT-365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15712904#comment-15712904
 ] 

ASF subversion and git services commented on MYNEWT-365:


Commit 0241d2f38e8236f03d6f20d5c7198d4a0a4cb169 in incubator-mynewt-newt's 
branch refs/heads/develop from [~ccollins476]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-mynewt-newt.git;h=0241d2f 
]

MYNEWT-365 newt can't handle files with spaces

Newt no longer invokes /bin/sh to execute external commands.  Instead,
it now uses the Go exec library to fork+exec child processes.

NOTE: This commit breaks backwards-compatibility with the Mynewt core
repo.  Specifically, the compiler.yml definitions indicated command line
options as a space-delimited sequence of strings in the path settings.
E.g., the Cortex M4 assembler specified the following path:

compiler.path.as: arm-none-eabi-gcc -x assembler-with-cpp

This compiler definition has now been changed to the following:

compiler.path.as: arm-none-eabi-gcc
compiler.as.flags: [-x, assembler-with-cpp]

We could have maintained backwards-compatibility by splitting paths on
spaces and interpreting secondary tokens as command-line options.
However, this approach prevents us from specifying a compiler path
that actually contains spaces.  I think paths with spaces is not
uncommon (e.g., "/Applications/GNU ARM Eclipse/...")

In addition, some packages' cflags contained shell-escaped strings
(e.g., backslash-quote).  These escapes had to be removed now that the
flags aren't passing through the shell.


> newt can't handle files with spaces
> ---
>
> Key: MYNEWT-365
> URL: https://issues.apache.org/jira/browse/MYNEWT-365
> Project: Mynewt
>  Issue Type: Bug
>  Components: Newt
>Affects Versions: v0_9_0
> Environment: Any
>Reporter: Tim
>Assignee: Christopher Collins
>Priority: Minor
>
> I was just looking at the code that decides where gcc is run from (so I can 
> see if I can make it always run from /workspace, so full paths are used), 
> when I noticed you don't handle program arguments properly.
> See [this 
> code|https://github.com/apache/incubator-mynewt-newt/blob/8abc4f2c2bb1ab784a854cdf5662e79d88a41407/newt/toolchain/compiler.go#L262]
> {code}
>   cmd += " -c " + "-o " + objPath + " " + file +
>   " " + c.cflagsString() + " " + c.includesString()
> {code}
> Command line arguments should be stored as a {{[]string}} instead of a 
> space-delimited {{string}}. Then you don't need to worry about spaces or 
> escaping or anything like that. In other words something like this:
> {code}
> func (c *Compiler) CompileFileCmd(file string,
>   compilerType int) ([]string, error) {
>   objFile := strings.TrimSuffix(file, filepath.Ext(file)) + ".o"
>   objPath := filepath.ToSlash(c.dstDir + "/" + objFile)
>   cmd := make([]string)
>   switch compilerType {
>   case COMPILER_TYPE_C:
>   cmd = cmd.append(c.ccPath)
>   case COMPILER_TYPE_ASM:
>   cmd = cmd.append(c.asPath)
>   default:
>   return nil, util.NewNewtError("Unknown compiler type")
>   }
>   cmd = append(cmd, "-c", "-o", objPath, file)
>   // There will be some special handling for these, depending on what 
> they contain (I'm not sure of the format of these exactly).
> //c.cflagsString(), c.includesString()
>   return cmd, nil
> }
> {code}
> And then don't use ShellCommand() to run it. Is there any reason that you're 
> using {{sh -c}} rather than just running the command directly? It's going to 
> make porting to Windows a pain. Similarly for code like this:
> {code}
> func CopyFile(srcFile string, destFile string) error {
>   _, err := ShellCommand(fmt.Sprintf("mkdir -p %s", 
> filepath.Dir(destFile)))
>   if err != nil {
>   return err
>   }
>   if _, err := ShellCommand(fmt.Sprintf("cp -Rf %s %s", srcFile,
>   destFile)); err != nil {
>   return err
>   }
>   return nil
> }
> {code}
> That won't work on Windows and also won't work with files containing spaces. 
> Better to use Go's proper functions for creating directories and copying 
> files. (Unfortunately there isn't a built-in equivalent of {{cp -Rf}} but if 
> you google it there is lots of example code.)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MYNEWT-365) newt can't handle files with spaces

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYNEWT-365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15712906#comment-15712906
 ] 

ASF subversion and git services commented on MYNEWT-365:


Commit 5c5a987ef72ae9b3eb682f19d7d0bdc85f7e500c in incubator-mynewt-core's 
branch refs/heads/develop from [~ccollins476]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-mynewt-core.git;h=5c5a987 
]

MYNEWT-365 newt can't handle files with spaces

This ticket's sister commit changed newt in a way that breaks
compatibility with the core repo.  This commit makes the core repo
compatible with newt again.

Newt no longer invokes /bin/sh to execute external commands.  Instead,
it now uses the Go exec library to fork+exec child processes.

NOTE: This commit breaks backwards-compatibility with the Mynewt core
repo.  Specifically, the compiler.yml definitions indicated command line
options as a space-delimited sequence of strings in the path settings.
E.g., the Cortex M4 assembler specified the following path:

compiler.path.as: arm-none-eabi-gcc -x assembler-with-cpp

This compiler definition has now been changed to the following:

compiler.path.as: arm-none-eabi-gcc
compiler.as.flags: [-x, assembler-with-cpp]

We could have maintained backwards-compatibility by splitting paths on
spaces and interpreting secondary tokens as command-line options.
However, this approach prevents us from specifying a compiler path
that actually contains spaces.  I think paths with spaces is not
uncommon (e.g., "/Applications/GNU ARM Eclipse/...")

In addition, some packages' cflags contained shell-escaped strings
(e.g., backslash-quote).  These escapes had to be removed now that the
flags aren't passing through the shell.


> newt can't handle files with spaces
> ---
>
> Key: MYNEWT-365
> URL: https://issues.apache.org/jira/browse/MYNEWT-365
> Project: Mynewt
>  Issue Type: Bug
>  Components: Newt
>Affects Versions: v0_9_0
> Environment: Any
>Reporter: Tim
>Assignee: Christopher Collins
>Priority: Minor
>
> I was just looking at the code that decides where gcc is run from (so I can 
> see if I can make it always run from /workspace, so full paths are used), 
> when I noticed you don't handle program arguments properly.
> See [this 
> code|https://github.com/apache/incubator-mynewt-newt/blob/8abc4f2c2bb1ab784a854cdf5662e79d88a41407/newt/toolchain/compiler.go#L262]
> {code}
>   cmd += " -c " + "-o " + objPath + " " + file +
>   " " + c.cflagsString() + " " + c.includesString()
> {code}
> Command line arguments should be stored as a {{[]string}} instead of a 
> space-delimited {{string}}. Then you don't need to worry about spaces or 
> escaping or anything like that. In other words something like this:
> {code}
> func (c *Compiler) CompileFileCmd(file string,
>   compilerType int) ([]string, error) {
>   objFile := strings.TrimSuffix(file, filepath.Ext(file)) + ".o"
>   objPath := filepath.ToSlash(c.dstDir + "/" + objFile)
>   cmd := make([]string)
>   switch compilerType {
>   case COMPILER_TYPE_C:
>   cmd = cmd.append(c.ccPath)
>   case COMPILER_TYPE_ASM:
>   cmd = cmd.append(c.asPath)
>   default:
>   return nil, util.NewNewtError("Unknown compiler type")
>   }
>   cmd = append(cmd, "-c", "-o", objPath, file)
>   // There will be some special handling for these, depending on what 
> they contain (I'm not sure of the format of these exactly).
> //c.cflagsString(), c.includesString()
>   return cmd, nil
> }
> {code}
> And then don't use ShellCommand() to run it. Is there any reason that you're 
> using {{sh -c}} rather than just running the command directly? It's going to 
> make porting to Windows a pain. Similarly for code like this:
> {code}
> func CopyFile(srcFile string, destFile string) error {
>   _, err := ShellCommand(fmt.Sprintf("mkdir -p %s", 
> filepath.Dir(destFile)))
>   if err != nil {
>   return err
>   }
>   if _, err := ShellCommand(fmt.Sprintf("cp -Rf %s %s", srcFile,
>   destFile)); err != nil {
>   return err
>   }
>   return nil
> }
> {code}
> That won't work on Windows and also won't work with files containing spaces. 
> Better to use Go's proper functions for creating directories and copying 
> files. (Unfortunately there isn't a built-in equivalent of {{cp -Rf}} but if 
> you google it there is lots of example code.)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MYNEWT-499) newt - APP_NAME value ambiguous for split images

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-499:
--

 Summary: newt - APP_NAME value ambiguous for split images
 Key: MYNEWT-499
 URL: https://issues.apache.org/jira/browse/MYNEWT-499
 Project: Mynewt
  Issue Type: Bug
  Components: Newt
Reporter: Christopher Collins
Assignee: Sterling Hughes


Newt automatically creates a few macros on the command line when it builds a 
target:

* {{ARCH_}}
* {{ARCH_NAME=""}}
* {{APP_}}
* {{APP_NAME=""}}
* {{BSP_}}
* {{BSP_NAME=""}}

There is a problem with the two APP defines.  A split image consists of two 
apps (the "loader" and the "app"), so there is not a single correct value to 
specify during compilation.

There are two issues here:

* Code cannot rely on consistent values for the APP defines when it is part of 
a split image
* Newt performs unnecessary compiling and linking operations for repeat builds 
of split targets.  This is because the command-line invocation changes between 
builds, as the APP name is not consistent.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MYNEWT-498) Newt - depgraph and syscfg calculate twice per build

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-498:
--

 Summary: Newt - depgraph and syscfg calculate twice per build
 Key: MYNEWT-498
 URL: https://issues.apache.org/jira/browse/MYNEWT-498
 Project: Mynewt
  Issue Type: Bug
Reporter: Christopher Collins
Assignee: Christopher Collins


Building with -ldebug shows that dependencies, syscfg, and APIs get resolved 
twice.  In the code, this happens in the following places:
* {{resolve/resolve.go (ResolveCfg())}}
* {{builder/build.go (PrepBuild())}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)