From: Guilherme B. T. <gui...@gm...> - 2014-01-14 22:45:38
|
Hi, I just added a set of experimental CMake configuration files for qucs-core to the master branch on SourceForge. These files do not interfere with the current Autotool build system. They are also not intended to replace Autotools! CMake has many nice features like I believe can be very helpful in the future for releasing/packaging Qucs sources and binaries to various platforms. I tested it on Linux, Mac and Windows. It is rather complete and comparable to the current Autotools build system. However it is still in development and at this moment just supported/maintained by me. Typically it is used for building out-of-the tree. You have to have AdmsXml already build (maybe with Autotools) before running CMake, besides all the other dependencies. Parallel build is also working okay. Its use is something along these lines: $cd ~/git/qucs/qucs-core $mkdir build $cd build $cmake .. -DCMAKE_INSTALL_PREFIX=/where/you/want/it/installed/ -DAMSXML_DIR=~/git/qucs/qucs-core/adms/admsXml/ $ make -j 4 $ make install These CMake files can also be used directly with QtCreator as IDE and integrated debugger. * Open the CMakeLists.txt with 'Open File or Project..." * Provide CMake arguments to: * Set path to existing admsXml path * Enable debug symbols for the debugger. * Add the following arguments to the 'Run CMake': -DAMSXML_DIR=~/git/qucs/qucs-core/adms/admsXml/ -DCMAKE_BUILD_TYPE:STRING=Debug I will try to keep it updated to the officially supported Autotools build system. Suggestions and patches are welcome. Best regards, Guilherme |
From: Luther T. C. <lut...@gm...> - 2014-01-15 02:44:14
|
Hello Guilherme, On 1/14/14, 4:45 PM, Guilherme Brondani Torri wrote: > Hi, > > I just added a set of experimental CMake configuration files for > qucs-core to the master branch on SourceForge. If you find it helpful, I've already made adms compile with CMake. Please see the project here: https://github.com/lutherthecat/ADMS It is forked from the very first upverter commit, which looks like a fork from ngspice: To compile: To install: cd ADMS bash create_files.sh mkdir cmake cd cmake cmake -DCMAKE_BUILD_TYPE=RELEASE .. make admsXml and admsCheck should be in ADMS/cmake/admsXml do not do parallel make (e.g. make -j2) until the bison generation is made safe. Note that this is easy port to any version of ADMS by copying any file named: create_files.sh CMakeLists.txt Regards, Luther > These files do not interfere with the current Autotool build system. > They are also not intended to replace Autotools! > CMake has many nice features like I believe can be very helpful in the > future for releasing/packaging Qucs sources and binaries to various > platforms. > > I tested it on Linux, Mac and Windows. It is rather complete and > comparable to the current Autotools build system. However it is still in > development and at this moment just supported/maintained by me. > > Typically it is used for building out-of-the tree. You have to have > AdmsXml already build (maybe with Autotools) before running CMake, > besides all the other dependencies. Parallel build is also working okay. > > Its use is something along these lines: > $cd ~/git/qucs/qucs-core > $mkdir build > $cd build > $cmake .. -DCMAKE_INSTALL_PREFIX=/where/you/want/it/installed/ > -DAMSXML_DIR=~/git/qucs/qucs-core/adms/admsXml/ > $ make -j 4 > $ make install > > These CMake files can also be used directly with QtCreator as IDE and > integrated debugger. > * Open the CMakeLists.txt with 'Open File or Project..." > * Provide CMake arguments to: > * Set path to existing admsXml path > * Enable debug symbols for the debugger. > * Add the following arguments to the 'Run CMake': > -DAMSXML_DIR=~/git/qucs/qucs-core/adms/admsXml/ > -DCMAKE_BUILD_TYPE:STRING=Debug > > I will try to keep it updated to the officially supported Autotools > build system. Suggestions and patches are welcome. > > Best regards, > Guilherme > > > ------------------------------------------------------------------------------ > CenturyLink Cloud: The Leader in Enterprise Cloud Services. > Learn Why More Businesses Are Choosing CenturyLink Cloud For > Critical Workloads, Development Environments & Everything In Between. > Get a Quote or Start a Free Trial Today. > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk > _______________________________________________ > Qucs-devel mailing list > Quc...@li... > https://lists.sourceforge.net/lists/listinfo/qucs-devel |
From: Guilherme B. T. <gui...@gm...> - 2014-01-15 08:58:20
|
On 15/01/14 03:44, Luther T. Cat wrote: > Hello Guilherme, > > > On 1/14/14, 4:45 PM, Guilherme Brondani Torri wrote: >> Hi, >> >> I just added a set of experimental CMake configuration files for >> qucs-core to the master branch on SourceForge. > If you find it helpful, I've already made adms compile with CMake. > Please see the project here: > https://github.com/lutherthecat/ADMS > Hi Luther, Thanks for the info! > > do not do parallel make (e.g. make -j2) until the bison generation is made safe. > > What do you mean by 'made safe'? It requires changes in the code or in the CMake files? Best regars, Guilherme |
From: Luther T. C. <lut...@gm...> - 2014-01-15 15:11:04
|
On 01/15/2014 02:58 AM, Guilherme Brondani Torri wrote: > On 15/01/14 03:44, Luther T. Cat wrote: >> Hello Guilherme, >> >> >> On 1/14/14, 4:45 PM, Guilherme Brondani Torri wrote: >>> Hi, >>> >>> I just added a set of experimental CMake configuration files for >>> qucs-core to the master branch on SourceForge. >> If you find it helpful, I've already made adms compile with CMake. >> Please see the project here: >> https://github.com/lutherthecat/ADMS >> > Hi Luther, > Thanks for the info! >> do not do parallel make (e.g. make -j2) until the bison generation is made safe. >> >> > What do you mean by 'made safe'? It requires changes in the code or in > the CMake files? Hi, In https://github.com/lutherthecat/ADMS/blob/master/admsXml/CMakeLists.txt: COMMAND bison ARGS -by -d -pveriloga verilogaYacc.y COMMAND mv ARGS -f y.tab.c verilogaYacc.c COMMAND mv ARGS -f y.tab.h verilogaYacc.h The mv command needs to be removed and the proper bison option must be specified to generate a specific filename. It is easy enough to do, but this was a direct transliteration of the old make. A parallel make would create multiple y.tab.c at the same time which belong to different files. Please note I added a default config.h, which is not generated. Regards, Luther > > Best regars, > Guilherme > > ------------------------------------------------------------------------------ > CenturyLink Cloud: The Leader in Enterprise Cloud Services. > Learn Why More Businesses Are Choosing CenturyLink Cloud For > Critical Workloads, Development Environments & Everything In Between. > Get a Quote or Start a Free Trial Today. > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk > _______________________________________________ > Qucs-devel mailing list > Quc...@li... > https://lists.sourceforge.net/lists/listinfo/qucs-devel |
From: roucaries b. <rou...@gm...> - 2014-01-15 20:28:33
|
On Wed, Jan 15, 2014 at 4:10 PM, Luther T. Cat <lut...@gm...> wrote: > On 01/15/2014 02:58 AM, Guilherme Brondani Torri wrote: >> On 15/01/14 03:44, Luther T. Cat wrote: >>> Hello Guilherme, >>> >>> >>> On 1/14/14, 4:45 PM, Guilherme Brondani Torri wrote: >>>> Hi, >>>> >>>> I just added a set of experimental CMake configuration files for >>>> qucs-core to the master branch on SourceForge. >>> If you find it helpful, I've already made adms compile with CMake. >>> Please see the project here: >>> https://github.com/lutherthecat/ADMS >>> >> Hi Luther, >> Thanks for the info! >>> do not do parallel make (e.g. make -j2) until the bison generation is made safe. >>> >>> >> What do you mean by 'made safe'? It requires changes in the code or in >> the CMake files? > > Hi, > > In > https://github.com/lutherthecat/ADMS/blob/master/admsXml/CMakeLists.txt: > > COMMAND bison > ARGS -by -d -pveriloga verilogaYacc.y > COMMAND mv > ARGS -f y.tab.c verilogaYacc.c > COMMAND mv > ARGS -f y.tab.h verilogaYacc.h > > > The mv command needs to be removed and the proper bison option must be > specified to generate a specific filename. It is easy enough to do, but > this was a direct transliteration of the old make. A parallel make > would create multiple y.tab.c at the same time which belong to different > files. Upverter take care of it it seems > > Please note I added a default config.h, which is not generated. > > Regards, > > Luther > >> >> Best regars, >> Guilherme >> >> ------------------------------------------------------------------------------ >> CenturyLink Cloud: The Leader in Enterprise Cloud Services. >> Learn Why More Businesses Are Choosing CenturyLink Cloud For >> Critical Workloads, Development Environments & Everything In Between. >> Get a Quote or Start a Free Trial Today. >> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk >> _______________________________________________ >> Qucs-devel mailing list >> Quc...@li... >> https://lists.sourceforge.net/lists/listinfo/qucs-devel > > > ------------------------------------------------------------------------------ > CenturyLink Cloud: The Leader in Enterprise Cloud Services. > Learn Why More Businesses Are Choosing CenturyLink Cloud For > Critical Workloads, Development Environments & Everything In Between. > Get a Quote or Start a Free Trial Today. > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk > _______________________________________________ > Qucs-devel mailing list > Quc...@li... > https://lists.sourceforge.net/lists/listinfo/qucs-devel |
From: roucaries b. <rou...@gm...> - 2014-01-15 20:30:57
|
On Tue, Jan 14, 2014 at 11:45 PM, Guilherme Brondani Torri <gui...@gm...> wrote: > Hi, > > I just added a set of experimental CMake configuration files for > qucs-core to the master branch on SourceForge. > > These files do not interfere with the current Autotool build system. > They are also not intended to replace Autotools! > CMake has many nice features like I believe can be very helpful in the > future for releasing/packaging Qucs sources and binaries to various > platforms. > > I tested it on Linux, Mac and Windows. It is rather complete and > comparable to the current Autotools build system. However it is still in > development and at this moment just supported/maintained by me. Please that we need a lot of work on configure system for library. >From my experience as debian maintainer of huge packet it is easier with autoconf (mangling custom rules, detection of crappy os...). Please add also test suite. I am not against cmake, but I will rather not kill autoconf for core. cmake is less flexible for crappy work than libtool/autoconf/automake and shared library are crappy. > Typically it is used for building out-of-the tree. You have to have > AdmsXml already build (maybe with Autotools) before running CMake, > besides all the other dependencies. Parallel build is also working okay. > > Its use is something along these lines: > $cd ~/git/qucs/qucs-core > $mkdir build > $cd build > $cmake .. -DCMAKE_INSTALL_PREFIX=/where/you/want/it/installed/ > -DAMSXML_DIR=~/git/qucs/qucs-core/adms/admsXml/ > $ make -j 4 > $ make install > > These CMake files can also be used directly with QtCreator as IDE and > integrated debugger. > * Open the CMakeLists.txt with 'Open File or Project..." > * Provide CMake arguments to: > * Set path to existing admsXml path > * Enable debug symbols for the debugger. > * Add the following arguments to the 'Run CMake': > -DAMSXML_DIR=~/git/qucs/qucs-core/adms/admsXml/ > -DCMAKE_BUILD_TYPE:STRING=Debug > > I will try to keep it updated to the officially supported Autotools > build system. Suggestions and patches are welcome. > > Best regards, > Guilherme > > > ------------------------------------------------------------------------------ > CenturyLink Cloud: The Leader in Enterprise Cloud Services. > Learn Why More Businesses Are Choosing CenturyLink Cloud For > Critical Workloads, Development Environments & Everything In Between. > Get a Quote or Start a Free Trial Today. > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk > _______________________________________________ > Qucs-devel mailing list > Quc...@li... > https://lists.sourceforge.net/lists/listinfo/qucs-devel |
From: Guilherme B. T. <gui...@gm...> - 2014-01-15 21:21:24
|
Hi Bastien, On 15/01/14 21:30, roucaries bastien wrote: > On Tue, Jan 14, 2014 at 11:45 PM, Guilherme Brondani Torri > <gui...@gm...> wrote: >> Hi, >> >> I just added a set of experimental CMake configuration files for >> qucs-core to the master branch on SourceForge. >> >> These files do not interfere with the current Autotool build system. >> They are also not intended to replace Autotools! >> CMake has many nice features like I believe can be very helpful in the >> future for releasing/packaging Qucs sources and binaries to various >> platforms. >> >> I tested it on Linux, Mac and Windows. It is rather complete and >> comparable to the current Autotools build system. However it is still in >> development and at this moment just supported/maintained by me. > Please that we need a lot of work on configure system for library. What exactly needs more work? Are you referring to Autotools or CMake? > From my experience as debian maintainer of huge packet it is easier > with autoconf (mangling custom rules, detection of crappy os...). I cannot comment on that I never maintained huge packages. As a maintainer yourself you probably know that there are some freaking large and complex projects which are build with CMake and are also available for debian. > > Please add also test suite. Which test suite are you referring to? > > I am not against cmake, but I will rather not kill autoconf for core. > cmake is less flexible for crappy work than libtool/autoconf/automake > and shared library are crappy. > > I am glad you are not against CMake. It stated clearly above that it is not meant to kill/replace Autotools. I don't want to start a build system war. However, contrary to what you say *in my opinion* CMake is more flexible, modern, shorter to write and easier to learn than autoconf/automake/m4/libtool/make... I am not a CMake specialist but from what I know it produces any kind of shared library. It is used by several heavy weight projects (KDE, Compiz, VTK, OpenSceneGraph, Trilinos, Inkscape, ReacOS, to name a few). I am not sure what do you mean with 'crappy'. Attacking one build system or another is meaningless. Even thou I mostly use vim to edit code, for me the ability to use the CMakeLists from the build system as projects into QtCreator is a big selling point. It can generate projects for many other IDEs. The packaging (CPack) can be extended to handle not only source release but also binary packages (RPM, deb, OSX bundles). Anyway, you probably knows all that. I know that having two build systems may seem like a waste of manpower. Still, I believe it is important to give the choice for users and developers. Best regards, Guilherme |
From: roucaries b. <rou...@gm...> - 2014-01-16 17:25:33
|
On Wed, Jan 15, 2014 at 10:21 PM, Guilherme Brondani Torri <gui...@gm...> wrote: > Hi Bastien, > > On 15/01/14 21:30, roucaries bastien wrote: >> On Tue, Jan 14, 2014 at 11:45 PM, Guilherme Brondani Torri >> <gui...@gm...> wrote: >>> Hi, >>> >>> I just added a set of experimental CMake configuration files for >>> qucs-core to the master branch on SourceForge. >>> >>> These files do not interfere with the current Autotool build system. >>> They are also not intended to replace Autotools! >>> CMake has many nice features like I believe can be very helpful in the >>> future for releasing/packaging Qucs sources and binaries to various >>> platforms. >>> >>> I tested it on Linux, Mac and Windows. It is rather complete and >>> comparable to the current Autotools build system. However it is still in >>> development and at this moment just supported/maintained by me. >> Please that we need a lot of work on configure system for library. > > What exactly needs more work? Are you referring to Autotools or CMake? >> From my experience as debian maintainer of huge packet it is easier >> with autoconf (mangling custom rules, detection of crappy os...). > > I cannot comment on that I never maintained huge packages. As a > maintainer yourself you probably know that there are some freaking large > and complex projects which are build with CMake and are also available > for debian. The best reason is gnulib. See the gnulib project for detail. Gnulib need autoconf/automake. It is a really good project and it is even used for glibc for internal testing. Note that it will alleviate the burden of porting. Unfortunatly it is not ported to cmake. Bastien >> Please add also test suite. > > Which test suite are you referring to? See make check with autoconf >> >> I am not against cmake, but I will rather not kill autoconf for core. >> cmake is less flexible for crappy work than libtool/autoconf/automake >> and shared library are crappy. >> >> > I am glad you are not against CMake. It stated clearly above that it is > not meant to kill/replace Autotools. > > I don't want to start a build system war. However, contrary to what you > say *in my opinion* CMake is more flexible, modern, shorter to write and > easier to learn than autoconf/automake/m4/libtool/make... Depend about the crappy stuff. For detecting bad function autoconf is more flexible, for casual usage it is cmake > > I am not a CMake specialist but from what I know it produces any kind of > shared library. It is used by several heavy weight projects (KDE, > Compiz, VTK, OpenSceneGraph, Trilinos, Inkscape, ReacOS, to name a few). > I am not sure what do you mean with 'crappy'. Attacking one build system > or another is meaningless. Crappy means sunos and stuff like this with strange compiler. > > Even thou I mostly use vim to edit code, for me the ability to use the > CMakeLists from the build system as projects into QtCreator is a big > selling point. It can generate projects for many other IDEs. The > packaging (CPack) can be extended to handle not only source release but > also binary packages (RPM, deb, OSX bundles). Anyway, you probably knows > all that. For gui it is a good point because qt abstract the os, for the core. Bastien > I know that having two build systems may seem like a waste of manpower. > Still, I believe it is important to give the choice for users and > developers. > > Best regards, > Guilherme > > ------------------------------------------------------------------------------ > CenturyLink Cloud: The Leader in Enterprise Cloud Services. > Learn Why More Businesses Are Choosing CenturyLink Cloud For > Critical Workloads, Development Environments & Everything In Between. > Get a Quote or Start a Free Trial Today. > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk > _______________________________________________ > Qucs-devel mailing list > Quc...@li... > https://lists.sourceforge.net/lists/listinfo/qucs-devel |