Closed info-rchitect closed 4 years ago
So far so good.
FYI, as far as file arguments go, the plan is for the CLI to deal with file arguments - so to sanitize/validate them, decompose lists into individual files, etc.
What this will mean for something like the compiler is that there will be an iterable that you can call, something like origen.input_files
, that you can iterate on or call next()
to get the next file in the queue.
This is tracked in #3.
That will arrive when it arrives and hack together whatever you need to get going right now, but bear in mind that the eventual plan is to integrate with a common file queue.
@ginty how will files be handled with programmatic compiler calls vs CLI?
That's up to you I suppose.
That's up to you I suppose.
OK then I think I am on the right track as this implementation should work with both.
Where should the output directory default to?
I would reference it back to origen.output_directory
for now, you'll have to add that attribute and set it to {origen.root}/example/output
or similar.
We can later hook that up to something from the application config.
Am I on the right track here?
@ginty How did you get the DUT loaded into the compiler scope in O1. As you can see in my implementation the user has to import origen
explicitly in their template file.
Python seems to have the concept of local variables and global variables within the scope of a given module (file). Here is an Origen method which returns what we should consider to be a standard set of globals available throughout an Origen application: https://github.com/Origen-SDK/o2/blob/978a1de758e37af571d43009911132961bd4525c/python/origen/__init__.py#L35
Here is an exec method being used to invoke a Python file with the specific variable context, maybe you can do something similar here - https://github.com/Origen-SDK/o2/blob/978a1de758e37af571d43009911132961bd4525c/python/origen/__init__.py#L31
@ginty Are we good to go for an initial compiler release?
Would like to see 'origen' and co auto-loaded before we close this
@coreyeng Something is broke wrt loading python libraries, can you check the travis config?
@info-rchitect, Master has been broken for a while now. The reorg somehow caused that. Not quite sure why it didn't pop up before, but I've fixed it on #79. You can either pull the travis config from there or ignore it for now and it'll be fixed when #79 gets merged.
@info-rchitect, Master has been broken for a while now. The reorg somehow caused that. Not quite sure why it didn't pop up before, but I've fixed it on #79. You can either pull the travis config from there or ignore it for now and it'll be fixed when #79 gets merged.
Thx @coreyeng for the help, I pulled it from your PR.
I'm trying to remember if there were any other changes needed. I think the 64-bit vs. 32-bit in the dict-like API may need bringing in too. Might be simple to wait for #79's merge if this build fails.
Actually, I think the above for list-like, which would be new in #79, so nevermind that.
@ginty @coreyeng We got 5/8 passing and the fails are not related to the compiler code. Are we good?
Looks like a genuine failure to me that should be fixed - looks like the compiler tests (or the compiler) doesn't handle Windows paths properly.
Can you also please merge latest master into this branch to clean up the diff and remove the file-handler-related diffs. Thanks!
@ginty @coreyeng I noticed this error in the Windows build:
872
Origen: INFO (00:00:00.000): 2.0.0-pre0
873
Is a suitable Python available? ... YES
874
Is the internet accessible? ... YES
875
Is a suitable Poetry available? ... NO
Is there an Origen log saying what failed in the origen setup
command?
That's not an un-recoverable failure, what happens after that? It should go on to install Poetry.
OK we clean!
Based on this issue. Should be able to demonstrate compiling with mako soon enough,.