[Scons-users] Dealing with an odd dependency
Matthew Swabey
mattaw at gmail.com
Tue Dec 9 10:36:15 EST 2014
I am trying a new approach with monkeypatching the FS.Dir() and FS.File()
into a vlib object with a custom builder (to invoke vlib) and to put in the
dependency orders in the File() based on scanning them for packages and
includes.
On 9 December 2014 at 09:13, Brian Cody <brian.j.cody at gmail.com> wrote:
> Matthew,
>
> It's nice to see someone take a completely different approach. I think the
> fact that we're building VHDL makes this a bit uglier for us versus
> verilog. The current solution we have (which works somehow!) is a single
> builder that both executes vlib and makes a modelsim ini.
>
> The original source/target to the builder (whatever you call it when you
> only supply one argument to a builder) is the list of _info files to be
> created by vlib. The emitter sets the target list to be an an ini file,
> plus the _info files. The source list becomes just a template modelsim ini
> (which has no local libraries listed). Emitter:
>
> def _emit_modelsim_libs_and_ini(target, source, env):
> new_targets = [os.path.join(os.path.dirname(str(source[0])),
> '../../modelsim.ini')] + source
> new_sources = [os.path.join('third-party/modelsim',
> env['BUILD_SPEC'] + '-template.ini')]
> env.SideEffect('phony vlib never ever created target', new_targets)
> return (new_targets, new_sources)
>
> The action of the builder copies the ini template to the destination, and
> then runs vlib and vmap for each _info target. We intentionally put
> abspaths in the ini file so that it can be used outside of the build by
> modelsim.
>
> def _create_modelsim_libs_and_ini(target, source, env):
> env.Execute(SCons.Script.Copy(target[0], source[0]))
> for library in [str(lib) for lib in target if
> str(lib).endswith('_info')]:
> lib_path = os.path.dirname(library)
> lib_name = os.path.basename(lib_path)
> exit_code = env.Execute(SCons.Script.Delete(lib_path))
> exit_code = exit_code or workarounds.execute_in_directory(env,
> os.path.dirname(lib_path), ['vlib', lib_name])
> exit_code = exit_code or env.Execute([['vmap',
> '-modelsimini',
> target[0],
> lib_name,
>
> os.path.abspath(lib_path)]])
> if exit_code != 0:
> break
> return exit_code
>
> One thing that I don't know that I really want explained to me is the best
> way to treat deal with unequal source lists or target lists. Here I assume
> that the ini file is the first target. That's a positional requirement and
> it feels icky. Alternatively I could loop over the entire list and fault if
> I find more than one ini file, and that seems like a lot of work. Ideally
> I'd like to be able to pass around dictionaries instead of lists for
> sources and targets. It'd really clean some things up.
>
> Another difference between your implementation and ours is that you
> compile individual source files with vcom. We scan through all the vhd
> files we want to compile, and through a scanner and toposort we figure out
> the required module order in the vcom statement. We've developed a (perhaps
> undeserved) mistrust of the modelsim compiler's ability to perform partial
> compilations.
>
> Also notice the 'workarounds'. The SCons chdir functionality is broken (it
> uses os.chdir), and as far as I can tell, vlib absolutely requires it. Our
> workaround uses subprocess with a specified work dir, like SCons ought to.
> Your version doesn't bother to change the working directory, so maybe we're
> using different versions of modelsim.
>
>
> On Mon, Dec 8, 2014 at 7:52 PM, Matthew Swabey <mattaw at gmail.com> wrote:
>
>> Here is my attempt to make modelsim behave with SCons. - it doesn't work
>> properly yet but would you like to collaborate on improving it. The main
>> issues surround identifying systemverilog packages and how to manage
>> discovering them and automatically finding the dependencies or do I expect
>> the user to manage it.
>>
>> Anyway this is from my site_scons and and example sconscript and
>> sconstruct.
>>
>> Let me know if you want to try to take things further - it would be great
>> to have a better solution to the horror that is modelsim (or I shall have
>> to use vcs!)
>>
>> Matthew
>>
>> On 5 December 2014 at 15:55, Dirk Bächle <tshortik at gmx.de> wrote:
>>
>>> On 05.12.2014 21:02, Brian Cody wrote:
>>>
>>>> Hey, no argument from me about SCons having a legitimate complaint.
>>>>
>>>> The tool is modelsim. Modelsim relies on an INI file to tell it where
>>>> things exist in your file system, e.g. lib_a is c:\here\liba, lib_b is
>>>> c:\here\libb, etc. The library is the location of where compiled objects
>>>> have been replaced. A caveat to this is that if lib B depends on lib A,
>>>> then lib A must be compiled and in the ini file before lib B is compiled.
>>>> Then if there's a lib C with a similar dependency on lib B, things start to
>>>> chain together.
>>>>
>>>> [...]
>>>>
>>>> The library creation does not depend on the ini file. They all can (and
>>>> do) run simultaneously. It really just creates a directory with a text file
>>>> with some internal modelsim information.
>>>> Next vcom can run on any library that depends on no other library.
>>>> Next vmap should be run to place those libraries in the ini file (vmap
>>>> would definitely need to treat the ini as a side effect at least)
>>>> Next vcom can run on any library that depends on just the previously
>>>> created libraries.
>>>> etc.
>>>>
>>>> I googled around a bit and had a short look at what Modelsim does:
>>>
>>> http://www.tkt.cs.tut.fi/tools/public/tutorials/mentor/
>>> modelsim/getting_started/gsms.html
>>>
>>> I would keep the "init" step of creating libraries separate from
>>> compiling them. You could define an option like "INIT", and when it's given
>>> on the command-line you only include an "SConscript.init" with the required
>>> steps to setup your libs. In "normal" mode, you include the main
>>> "SConscript" for running the compiler on the libraries. (could also be
>>> solved using Aliases, I guess)
>>> About the vcom/vmap commands: you could try to define your Builder from
>>> a "list of actions", such that it always automatically runs "vmap" after
>>> your actual build command. Then you would probably have to define your
>>> *.ini file as both, SideEffect() and Precious().
>>>
>>> Regards,
>>>
>>> Dirk
>>>
>>>
>>>
>>> _______________________________________________
>>> Scons-users mailing list
>>> Scons-users at scons.org
>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>
>>
>>
>> _______________________________________________
>> Scons-users mailing list
>> Scons-users at scons.org
>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20141209/c5b53bff/attachment-0001.html>
More information about the Scons-users
mailing list