From: Richard C. <r.c...@ed...> - 2014-03-28 10:48:25
|
Hello all, Yesterday I posted the sources of ADMS on the original sourceforge page in a Git repo. These were a direct copy of the ones in our repository. What do we think of removing adms from our source tree and having the adms repo as a git submodule instead? I could add some more qucs developers as admins to ADMS for safety. The ADMS sourceforge page has a couple of patches submitted, does anyone have any opinion on this one submitted two days ago? https://sourceforge.net/p/mot-adms/patches/3/ Apparently it brings "the list of functions ADMS will recognize in line with the list from the LRM v2.2". Richard -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. |
From: Guilherme B. T. <gui...@gm...> - 2014-03-30 00:02:11
|
Hi Richard, On 3/28/14, 10:48 AM, Richard Crozier wrote: > Hello all, > > Yesterday I posted the sources of ADMS on the original sourceforge page > in a Git repo. These were a direct copy of the ones in our repository. > What do we think of removing adms from our source tree and having the > adms repo as a git submodule instead? I haven't used git submodules up to now. I just saw people comparing submodule and subtree. Do you have an opinion on that? I suggest we do this after the next Qucs release. > I could add some more qucs developers as admins to ADMS for safety. Later on I would like to have write access to the repo. I already started reading the code and making notes, soon I will hacking with it. > > The ADMS sourceforge page has a couple of patches submitted, does anyone > have any opinion on this one submitted two days ago? > > https://sourceforge.net/p/mot-adms/patches/3/ > > Apparently it brings "the list of functions ADMS will recognize in line > with the list from the LRM v2.2". As Mike said I think the patch is okay. A few more things to be considered: 1) Mike and I discussed about extending ADMS coverage of the Verilog-A(MS) as per LRM. We should soon (after the next Qucs release) start with ADMS extension and testing infrastructure. 2) merge/cherry-pick the Upverter branch (https://github.com/upverter/ADMS/tree/upverter). It is basically the same initial commit but it underwent a major cleanup of old cruft and even a few new features. I think it is really worth to have a look and integrate the commits from there. 3) include CMake build, based on (https://github.com/lutherthecat/ADMS/commits/master). Clemens was looking into this. 4) Documentation. There are (not many) bits and pieces in different places, maybe we should put them into one place (wiki maybe?) 5) I would suggest we use GitHub as main repo and SourceForge for stable tarballs. The issue tracker, the wiki, the github.io webpages and pull-requests are much more fluid and convenient. Regards, Guilherme |
From: Richard C. <r.c...@ed...> - 2014-03-30 11:54:39
|
> > I haven't used git submodules up to now. I just saw people comparing > submodule and subtree. Do you have an opinion on that? > No, and I'm happy to take advice on this. I did read a little though, and from what I read, it seemed like git submodules was designed for this use case, keeping an entirely separate self-contained project in your project's source tree. > I suggest we do this after the next Qucs release. > Yep, no rush on this. >> I could add some more qucs developers as admins to ADMS for safety. > > Later on I would like to have write access to the repo. I already > started reading the code and making notes, soon I will hacking with it. > I'll probably just add you some time next week if you like. >> >> The ADMS sourceforge page has a couple of patches submitted, does anyone >> have any opinion on this one submitted two days ago? >> >> https://sourceforge.net/p/mot-adms/patches/3/ >> >> Apparently it brings "the list of functions ADMS will recognize in line >> with the list from the LRM v2.2". > > As Mike said I think the patch is okay. > > A few more things to be considered: > > 1) Mike and I discussed about extending ADMS coverage of the > Verilog-A(MS) as per LRM. We should soon (after the next Qucs release) > start with ADMS extension and testing infrastructure. I agree, one of the first things we could use is a method of testing and verifying any changes we might make to ADMS. > 2) merge/cherry-pick the Upverter branch > (https://github.com/upverter/ADMS/tree/upverter). It is basically the > same initial commit but it underwent a major cleanup of old cruft and > even a few new features. I think it is really worth to have a look and > integrate the commits from there. I would even be happy to just mirror the Upverter repo if we knew it worked with Qucs, and they were open to our patches. I don't really want to fork ADMS. I would like to host downloads on sourceforge though. > 3) include CMake build, based on > (https://github.com/lutherthecat/ADMS/commits/master). Clemens was > looking into this. Yes, well I'm also starting to come around to cmake too. > 4) Documentation. There are (not many) bits and pieces in different > places, maybe we should put them into one place (wiki maybe?) Yes, I also went through the old ADMS mailing list and picked out a few possibly interesting/relevant posts and put them on a wiki page on the SF ADMS page for safe keeping. I also added some comments to a few ADMS source files in our version (and now the sourceforge version). > 5) I would suggest we use GitHub as main repo and SourceForge for stable > tarballs. The issue tracker, the wiki, the github.io webpages and > pull-requests are much more fluid and convenient. > I'm ok with this, however, could you possibly add me to the appropriate repos on Github? My Github username is crobarcro, same as sourceforge. Re Github, I think from a collaboration perspective it's great, it also has a much nicer interface for browsing the git sources. However, from a 'marketing' perspective, I think Sourceforge is better. > > Regards, > Guilherme > Regards, Richard -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. |
From: Guilherme B. T. <gui...@gm...> - 2014-04-03 00:00:50
|
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 |
From: Luther T. C. <lut...@gm...> - 2014-04-03 00:32:39
|
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 |
From: mike b. <mbr...@ya...> - 2014-04-03 10:28:57
|
Some comments and thoughts on ADMS. 1. I have downloaded ADMS-cleanup from guitorri/ADMS and find it compiles and runs using Autotools. 2. I am very much in favour of generating a new ADMS repo on the Qucs Organisation (under Git). Once this is done we will all know which is the current repo which applies to Qucs. Upverter is OK BUT it is centred around ngspice. Hence the code generation xml files are different to the ones written for Qucs. 3. Regarding testing methods I rather like the approach taken by Verlog icarus. Given time we could build up a set of modules which test the various Verilog-A constructions - both the passer and xml code generation scripts. 4. Much work needs to be done at this stage in checking the currently implemented parts of Verilog-AMS to confirm how well Qucs meets the Verilog-AMS 2.3 standard. Initial checks show that there are more deviations than originally realised. Mike Mike Brinson mbr...@ya... On Thursday, 3 April 2014, 1:33, Luther T. Cat <lut...@gm...> 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 |
From: Guilherme B. T. <gui...@gm...> - 2014-04-03 10:37:11
|
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 |
From: Luther T. C. <lut...@gm...> - 2014-04-03 14:07:37
|
On 4/3/14, 5:37 AM, Guilherme Brondani Torri wrote: > 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. If you look at the config.h that was checked in, there is nothing actually compelling in the file. #ifndef CONFIG_H_FILE #define CONFIG_H_FILE #define HAVE_STDLIB_H 1 #define HAVE_SYS_STAT_H 1 #define HAVE_STRING_H 1 #define PACKAGE_NAME "adms" #define PACKAGE_VERSION "2.3.0" #define PACKAGE_BUGREPORT "lutherthecat@github" #endif The name, version and maintainer is just as easily defined on the compiler command line. Anything that is WIN32 specific is in the affected source files. CTEST configuration is quite easy to setup. Each test would just have to return a 0 (success) or nonzero when it is done. Juan > > 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 > > ------------------------------------------------------------------------------ > _______________________________________________ > Qucs-devel mailing list > Quc...@li... > https://lists.sourceforge.net/lists/listinfo/qucs-devel |
From: Guilherme T. <gui...@gm...> - 2014-04-03 15:49:23
|
On Thu, Apr 3, 2014 at 4:07 PM, Luther T. Cat <lut...@gm...> wrote: > > On 4/3/14, 5:37 AM, Guilherme Brondani Torri wrote: > > 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. > If you look at the config.h that was checked in, there is nothing > actually compelling in the file. > > #ifndef CONFIG_H_FILE > #define CONFIG_H_FILE > #define HAVE_STDLIB_H 1 > #define HAVE_SYS_STAT_H 1 > #define HAVE_STRING_H 1 > #define PACKAGE_NAME "adms" > #define PACKAGE_VERSION "2.3.0" > #define PACKAGE_BUGREPORT "lutherthecat@github" > #endif > > The name, version and maintainer is just as easily defined on the > compiler command line. Anything that is WIN32 specific is in the > affected source files. > > CTEST configuration is quite easy to setup. Each test would just have > to return a 0 (success) or nonzero when it is done. > > Juan > Hi Juan, Configuration might be critical for portability. I haven't looked carefully at which `#if defined` are used on the code. Anyway, you missed HAVE_LOCALE_H. Perhaps the easiest is to copy the ` config.h.in` generated by autoheader and tweak it to be used by CMake. I think the standard CMake way of doing this is to do set variables on the top-most CMakeLists.txt (version, names, ...) and do the platform checks you need, set variables and configure/replace results on a config.h template (config.h.in or config.h.cmake). I followed this to implement such a thing for the qucs sources: http://www.vtk.org/Wiki/CMake:How_To_Write_Platform_Checks Regards, Guilherme <snip> |
From: luther c. <lut...@gm...> - 2014-04-03 16:18:39
|
response inline On Thu, Apr 3, 2014 at 10:49 AM, Guilherme Torri <gui...@gm...> wrote: > > On Thu, Apr 3, 2014 at 4:07 PM, Luther T. Cat <lut...@gm...>wrote: > >> >> On 4/3/14, 5:37 AM, Guilherme Brondani Torri wrote: >> > 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. >> If you look at the config.h that was checked in, there is nothing >> actually compelling in the file. >> >> #ifndef CONFIG_H_FILE >> #define CONFIG_H_FILE >> #define HAVE_STDLIB_H 1 >> #define HAVE_SYS_STAT_H 1 >> #define HAVE_STRING_H 1 >> #define PACKAGE_NAME "adms" >> #define PACKAGE_VERSION "2.3.0" >> #define PACKAGE_BUGREPORT "lutherthecat@github" >> #endif >> >> The name, version and maintainer is just as easily defined on the >> compiler command line. Anything that is WIN32 specific is in the >> affected source files. >> >> CTEST configuration is quite easy to setup. Each test would just have >> to return a 0 (success) or nonzero when it is done. >> >> Juan >> > > Hi Juan, > > Configuration might be critical for portability. > > I haven't looked carefully at which `#if defined` are used on the code. > Anyway, you missed HAVE_LOCALE_H. Perhaps the easiest is to copy the ` > config.h.in` generated by autoheader and tweak it to be used by CMake. > > HAVE_LOCALE_H includes locale.h, which isn't needed for anything. I started with the generated config.h from autotools and commented everything out and worked backwards. Regards, Luther > I think the standard CMake way of doing this is to do set variables on the > top-most CMakeLists.txt (version, names, ...) and do the platform checks > you need, set variables and configure/replace results on a config.h > template (config.h.in or config.h.cmake). > > I followed this to implement such a thing for the qucs sources: > http://www.vtk.org/Wiki/CMake:How_To_Write_Platform_Checks > > Regards, Guilherme > > <snip> > |