Hi,
can somebody help me to remember why do we have a device _and_ an architecture entry in our project configuration files? An device should be enough or do we have devices with multiple architectures?
Georgi
Zeige Antworten nach Diskussionsstrang
Hi Georgi,
On Wed 18 Sep 2013 10:21:54 PM CEST, Georgi Grinshpun wrote:
can somebody help me to remember why do we have a device _and_ an architecture entry in our project configuration files?
This is because until recently we did not have enough information to look up architectures by device names.
An device should be enough or do we have devices with multiple architectures?
Since we now have our XML Device Files on the feature/experimental_structure branch we could remove the architecture setting from the project.cfg and do a look up for the architecture in our scons tools.
I think Niklas wanted to overhaul our project.cfg format anyway to make it easier to use and to get rid of redundancies like the one you pointed out.
Kevin
Hi,
On Wed 18 Sep 2013 10:21:54 PM CEST, Georgi Grinshpun wrote:
can somebody help me to remember why do we have a device _and_ an architecture entry in our project configuration files?
This is because until recently we did not have enough information to look up architectures by device names.
Exactly. In xpcc.io we have a lot more meta data about device configuration. I think the architecture entry is not even evaluated anymore.
An device should be enough or do we have devices with multiple architectures?
Since we now have our XML Device Files on the feature/experimental_structure branch we could remove the architecture setting from the project.cfg and do a look up for the architecture in our scons tools.
Yes.
I think Niklas wanted to overhaul our project.cfg format anyway to make it easier to use and to get rid of redundancies like the one you pointed out.
I wanted to get rid of the SConstruct file, since for most projects the data in it is always the same (dependent on architecture). But that is not how SCons works :-(
Cheers, Niklas
Hi,
On Wed 18 Sep 2013 10:21:54 PM CEST, Georgi Grinshpun wrote:
can somebody help me to remember why do we have a device _and_ an architecture entry in our project configuration files?
This is because until recently we did not have enough information to look up architectures by device names.
Exactly. In xpcc.io we have a lot more meta data about device configuration.
What is "xpcc.io"?
I think Niklas wanted to overhaul our project.cfg format anyway to make it easier to use and to get rid of redundancies like the one you
pointed
out.
I wanted to get rid of the SConstruct file, since for most projects the data in it is always the same (dependent on architecture). But that is not how SCons works :-(
Together with that activity I would suggest to make the different SCons Tools separable. I started this for my work because I needed to have the basic SCons tools without the remaining xpcc library. It mainly needs a few clearly defines interfaces (ways to exchange data through the environment). I can merge my changes back, but it will certainly break the current xpcc tool. If we are already changing that tool it would be a good time out to do that.
Fabian
Hi,
can somebody help me to remember why do we have a device _and_ an architecture entry in our project configuration files? An device should be enough or do we have devices with multiple architectures?
The architecture selected the SCons tool to use and the device was given directly to the Tool without really looking at its content. It is a bit different now, but that was the original reasoning.
Fabian
Moin,
On Wed 18 Sep 2013 10:21:54 PM CEST, Georgi Grinshpun wrote:
can somebody help me to remember why do we have a device _and_ an architecture entry in our project configuration files?
This is because until recently we did not have enough information to look up architectures by device names.
Exactly. In xpcc.io we have a lot more meta data about device configuration.
What is "xpcc.io"?
The lazy way of saying "the unstable experimental_structure feature branch of XPCC". I used to call it "xpcc NextGen" or "xpcc NG", but "xpcc.io" is a little more useful, because it includes the URL too. You know "branding 'n stuff" ;-)
I think Niklas wanted to overhaul our project.cfg format anyway to make it easier to use and to get rid of redundancies like the one you
pointed
out.
I wanted to get rid of the SConstruct file, since for most projects the data in it is always the same (dependent on architecture). But that is not how SCons works :-(
Together with that activity I would suggest to make the different SCons Tools separable. I started this for my work because I needed to have the basic SCons tools without the remaining xpcc library. It mainly needs a few clearly defines interfaces (ways to exchange data through the environment). I can merge my changes back, but it will certainly break the current xpcc tool. If we are already changing that tool it would be a good time out to do that.
Any chance you can give us what you already have? Maybe a feature branch or just provide a dl link of the zipped raw code?
Cheers, Niklas
Hi,
I think Niklas wanted to overhaul our project.cfg format anyway to make it easier to use and to get rid of redundancies like the one you
pointed
out.
I wanted to get rid of the SConstruct file, since for most projects the data in it is always the same (dependent on architecture). But that is not how SCons works :-(
Together with that activity I would suggest to make the different SCons Tools separable. I started this for my work because I needed to have the basic SCons tools without the remaining xpcc library. It mainly needs a few clearly defines interfaces (ways to exchange data through the environment). I can merge my changes back, but it will certainly break the current xpcc tool. If we are already changing that tool it would be a good time out to do that.
Any chance you can give us what you already have? Maybe a feature branch or just provide a dl link of the zipped raw code?
I should read first. Yes, please merge it into the experimental_structure branch.
Cheers, Niklas
On 09/19/2013 11:46 AM, Niklas Hauser wrote:
Together with that activity I would suggest to make the different SCons Tools separable. I started this for my work because I needed to have the basic SCons tools without the remaining xpcc library. It mainly needs a few clearly defines interfaces (ways to exchange data through the environment). I can merge my changes back, but it will certainly break the current xpcc tool. If we are already changing that tool it would be a good time out to do that.
I should read first. Yes, please merge it into the experimental_structure branch.
Please do not merge it into feature/experimental_structure because as you point out: "it will certainly break the current xpcc tool". It would be better if you could put the changes on a separate feature branch and push it to our repository on github. I will then try to rebase the changes on top of our feature/experimental_structure branch.
Kevin
Am 09/19/13, schrieb Kevin Laeufer kevin.laeufer@rwth-aachen.de:
On 09/19/2013 11:46 AM, Niklas Hauser wrote:
Together with that activity I would suggest to make the different SCons Tools separable. I started this for my work because I needed to have the basic SCons tools without the remaining xpcc library. It mainly needs a few clearly defines interfaces (ways to exchange data through the environment). I can merge my changes back, but it will certainly break the current xpcc tool. If we are already changing that tool it would be a good time out to do that.
I should read first. Yes, please merge it into the experimental_structure branch.
Please do not merge it into feature/experimental_structure because as you point out: "it will certainly break the current xpcc tool". It would be better if you could put the changes on a separate feature branch and push it to our repository on github. I will then try to rebase the changes on top of our feature/experimental_structure branch.
May be a candidate for 2015. Now we have to concentrate experimental branch. Don't start merging further features together, but merging experimental into develop.
Georgi
-
Fabian Greif -
Georgi Grinshpun -
Georgi Grinshpun
-
Kevin Laeufer -
Niklas Hauser