Re: [Qucs-devel] ADMS

[Guilherme B. T. <gui...@gm...>]

Hi,

Yes, your solution of removing the %define api.prefix from the Bison 
file and passing it as a parameter works fine for most versions of Bison.

I just could not find an easy way to do it with Autotools. Hence I 
decided to tradeoff to enable both build systems.

We cannot just throw away Autotools. If we ever do, we first give 
deprecation warning, drop support and then forget about it.

Furthermore, CMake is not currently doing any of the tests, 
configuration of config.h, nor uninstall.

So, CMake needs further work.

Regards,
Guilherme

On 4/3/14, 2:32 AM, Luther T. Cat wrote:
> The CMAKE version I wrote supports earlier versions of BISON.  It passes
> the proper prefix option on the BISON command line.  The code is in the
> root level CMakeLists.txt.
>
> Since you left the api.prefix in BISON file, you should have CMAKE
> output an error.
>
> Thanks,
>
> Luther
>
> On 4/2/14, 7:00 PM, Guilherme Brondani Torri wrote:
>> Hello,
>>
>> Some comments about the ADMS repo. I also did now want to fork it, but
>> if we are going to take the lead and push ADMS forward, a role as
>> maintainer seems inevitable.
>>
>> Please have a look at https://github.com/guitorri/ADMS/tree/cleanup
>>
>> I started with the initial commit from Upverter (which was the last
>> released adms-2.3.0 tarball with all the svn stuff in it).
>> This initial commit was then tagged as v2.3.0.
>> I also selected mostly commits from three locations related to cleanup
>> and build scripts from either the Upverter branch, or lutherthecat, or
>> from our own repo. I will try to diff against the ngspice version to
>> check if there are significant differences.
>> The commits where sorted and squashed together where possible.
>> For now I ignored the new parser features introduced by Upverter. Let us
>> tidy it up before start adding features.
>>
>> So far both autotools and cmake should be working (tested with bison
>> 2.7.1 and 3.0.2). See Readme.
>>
>> Can you please give it a try? Maybe we can use this as our ADMS master
>> from now on.
>> Next, as we go we should put together the bits and pieces of
>> documentation we can find or produce.
>> I want to squash the other Upverter feature commits, just to make it
>> easier to see what went on.
>>
>> Richard can we rename the default git repo on SF? It refers to something
>> with mot-adms.
>> In your first commit your email is also not set <us...@ex...>.
>> I already added you as owner into the https://github.com/Qucs organization.
>>
>> If you all agree I will create a new repo on the Qucs Organization to
>> hold ADMS.
>>
>> Concerning automated compiler testing. I found the following links very
>> interesting:
>> http://dstress.kuehne.cn/www/dstress.html
>> http://www.gnu.org/software/dejagnu/
>> http://llvm.org/docs/CommandGuide/lit.html
>> https://github.com/steveicarus/ivtest
>>
>> I don't know exactly how we are going to implement it. ADMS is an
>> interesting piece of software. To test the parser and internal tree is
>> one thing, but we also need to have and test xml templates to emit
>> compilable code to run. Somehow we need to check the parser and code
>> generation. If we want LRM compliance, it will be quite a job. Loops and
>> other algorithmic constructor can be mapped to, say, C++. Other things
>> might need the simulator backend with the adequate machinery.
>>
>> Does anyone knows about Verilog-A validation suites available out there?
>> http://www.powershow.com/view1/18078a-ZDc1Z/VerilogA_Validation_Suite_Proposals_powerpoint_ppt_presentation
>>
>> Does anyone knows if there are other Verilog-A compilers that we would
>> have access to?
>> The company/spinoff listed below went out of business... Maybe the code
>> is available somewhere?
>> http://mixedsignal.eleg.uark.edu/groups_cad/index.html
>>
>> On a side note, the above link also mentions fREEDA
>> (http://www.freeda.org/index.html), which seems not to be developed
>> anymore. I got is to compile a year ago, but never used it. They forked
>> an early version of the Qucs GUI. The backend seems interesting, and
>> they had lots of publications. Apparently they also used automatic
>> differentiation (ADOL-C). It mentions GPL in some places and BSD in
>> others... Not sure. It might be interesting to have a further look.
>>
>> So, that was it for the moment.
>> I will try to merge the dynamic-loader work till next weekend, shall we
>> start preparing for a release?
>>
>> Regards,
>> Guilherme
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Qucs-devel mailing list
>> Quc...@li...
>> https://lists.sourceforge.net/lists/listinfo/qucs-devel
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Qucs-devel mailing list
> Quc...@li...
> https://lists.sourceforge.net/lists/listinfo/qucs-devel