Jump to content

katang

Members
  • Content Count

    81
  • Joined

  • Last visited

About katang

  • Rank
    Advanced Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. First of all, thank you for the quick and effective help. To be frank, I found the conan approach attractive because otherwise it is rather tedious to start up a new project; I guess the same feeling triggered you to assemble and publish the package. My naive idea was that both myself when I assemble a new working environment as well as my users installing the package on their own system, will set up the system using conan (i.e. we do not need to hunt down the individual packages, sometimes finding version compatibility problems), and after that we can rely on the CMake environment as before. That is I do not need conan in the followings, but I need it heavily when I start up. So, the ideal would be not a "CMake only" (where I DO NEED to deal with the packages and their dependencies), and not a "conan only" (where I come out from the normal CMake environment) handling. I would prefer the combined way. Maybe you should have a look at the the package and devote a couple of sentences in the readme file to this aspect. I think that what you call "conan-only" version, meets my needs (except that in the section "Build the project (it will download the needed libraries) and run it:" after cmake .. a make shall also be inserted). I think it is a very useful contribution, especially for the beginners and non-professional developers. I think, however, that every single development must start immediately at the very beginning with testing; so it would be great to complete this contribution with a testing example. I would suggest to make one more update. In the conanfile.txt you say [options] SystemC:stdcxx=14 and in CMakeLists.txt set(CMAKE_CXX_STANDARD 14) set(CMAKE_CXX_STANDARD_REQUIRED ON) set(CMAKE_CXX_EXTENSIONS OFF) find_package(SystemC REQUIRED) if(SystemC_FOUND) As the SystemC (AFAIK) defaults standard to '98 and it can be set independently; it may make confusion if you use this makefile with another sources, compiled independently (library version mismatch). In my own sources I use set (CMAKE_CXX_STANDARD ${SystemC_CXX_STANDARD} CACHE STRING "C++ standard to build all targets. Supported values are 98, 11, and 14.") of course after find_package(SystemCLanguage CONFIG REQUIRED) I think this can prevent some potential questions and bugs. (BTW: SystemC or SystemClanguage is the preferred utilization)
  2. Well, up to that point is everything fine. In the next step I attempt to add gtest using line gtest/1.8.1@bincrafters/stable The message is $ make [ 50%] Linking CXX executable bin/TransactionExample /usr/bin/ld: cannot find -lgmock_maind /usr/bin/ld: cannot find -lgmockd /usr/bin/ld: cannot find -lgtestd collect2: error: ld returned 1 exit status CMakeFiles/TransactionExample.dir/build.make:94: recipe for target 'bin/TransactionExample' failed make[2]: *** [bin/TransactionExample] Error 1 CMakeFiles/Makefile2:67: recipe for target 'CMakeFiles/TransactionExample.dir/all' failed make[1]: *** [CMakeFiles/TransactionExample.dir/all] Error 2 Makefile:83: recipe for target 'all' failed make: *** [all] Error 2 well, I understood that gmock is missing, but AFAIN since 1.8.0 it should come with gtest. In addition, the dependencies are about something similar. No difference if I use conan; somehow gtest depencence is missed.
  3. I recently discovered the conan-style install, but I have difficulties with using it. I started with the quickstart example. My conanfile.txt contains [requires] SystemC/2.3.3@minres/stable SystemCVerification/2.0.0a@minres/stable gtest/1.8.1@bincrafters/stable flex/2.6.4@bincrafters/stable qt5/5.13.0@bincrafters/stable and $ conan remote list conan-center: https://conan.bintray.com [Verify SSL: True] minres: https://api.bintray.com/conan/minres/conan-repo [Verify SSL: True] flex: https://github.com/bincrafters/conan-flex [Verify SSL: True] qt5: https://github.com/bincrafters/conan-qt [Verify SSL: True] gtest: https://github.com/bincrafters/conan-gtest [Verify SSL: True] Shall I do anything else? With this, I receive the message $ sudo conan install .. --build=missing Configuration: [settings] arch=x86_64 arch_build=x86_64 build_type=Release compiler=gcc compiler.libcxx=libstdc++ compiler.version=7 os=Linux os_build=Linux [options] [build_requires] [env] WARN: SystemCVerification/2.0.0a@minres/stable requirement SystemC/2.3.2@minres/stable overridden by your conanfile to SystemC/2.3.3@minres/stable flex/2.6.4@bincrafters/stable: Not found in local cache, looking in remotes... flex/2.6.4@bincrafters/stable: Trying with 'conan-center'... flex/2.6.4@bincrafters/stable: Trying with 'minres'... flex/2.6.4@bincrafters/stable: Trying with 'flex'... flex/2.6.4@bincrafters/stable: Trying with 'qt5'... flex/2.6.4@bincrafters/stable: Trying with 'gtest'... ERROR: Unable to find 'flex/2.6.4@bincrafters/stable' in remotes I.e. gtest can be installed with conan, the rest not ; the same happens with the command line $ conan install qt/5.13.0@bincrafters/stable Do I wrong something? BTW: I receive the message WARN: SystemCVerification/2.0.0a@minres/stable requirement SystemC/2.3.2@minres/stable overridden by your conanfile to SystemC/2.3.3@minres/stable Which is true, I really changed in the conanfile.txt to 2.3.3. Maybe SystemCVerification should be updated. Also, I wanted to install TLM. Does it have similar conan recipe and store?
  4. I have found in the examples of the SCFTGU book examples "a heartbeat function similar to a clock except it is more efficient than an sc_signal<bool>." It is used in one of the examples of the next chapter, but not at all in later examples, like the ones appended to 2.3.3. Is there any specific reason of it? Also, if defines only posedge_event() ; Can it be used in the simple_bus example, where negedge is also used?
  5. https://matthieu-moy.fr/sc-during/doc/html/index.html I have found some library, which for the first look sound interesting and useful Is there any collective experience with it?
  6. It will install to any directory you want. Is there any reason why this simple advice ins not written in the installation instructions? Without this s CMAKE_INSTALL_PREFIX remains undefined,, as I told.
  7. Hello Ameya Vikram Singh, As per the CMake documentation you cited: This means (for me, at least), that it is initialized "on the first run of CMake ", i.e. it is uninitialized during the first run. I also told, that on a "virgin" system during the first run setting the CMAKE_INSTALL_PREFIX is protected by an if(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT) block. I.e. when I install CMake for the first time (2.3.2 or above) it WILL NOT SET my CMAKE_INSTALL_PREFIX to the newly installed version, and it leads to countless hours of debugging. The installation instructions do not mention how to install the new version for the unlucky gui, who did successfully install previously 2.3.1 and is not member of the developer team, and so does not know what is not mentioned in the installation instructions. For those who start with at least 2.3.2, it is not a problem. I found the solution as to comment out the protection. That solved my problem, but probably is not the right way to install SystemC. Otherwise even now, after my questions and answers of the experts, I do not know what is the right way of installing the new version, when some other project already uses an older version of SystemC, and because of this, the install script directs the linker to the wrong version.
  8. Maybe this is the intention, but it does not do so: when I run it in the first time, it simply leaves CMAKE_INSTALL_PREFIX undefined, since the settings you mention are only read inside this if-protected lines. In my eyes a very bad idea to leave and undefined initial value in a code, by intention. Yes, it is. And is is also time-wasting. BTW: it is the first time I saw that the CMAKE_INSTALL_PREFIX is to be set manually. The readme attached to the library mentions that it is one one the very important variables, but does not mention it shall be set manually. It does not help a lot. It is a long time to hunt down that this is the reason, and after that I see that environtal variables are only read inside these protected lines. No warning, no docs. Maybe good for developers (just seconds to use), but days for users to figure this out.
  9. Then my bet is that on your system CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT is defined somehow. Otherwise line 541 if (CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT) prevents to define, among others CMAKE_INSTALL_PREFIX After that I commented out that conditional, I also succeeded. BTW: what that conditional makes there? I do not think it is properly used According to CMake docs, that is, when I run CMake for the first time, it will not set CMAKE_INSTALL_PREFIX at all, that is it will be installed to the default path, independently of whether I have defined my own (initially obviously experimental) path. So, my initial attempt with a new version will fail. I would suggest to make an install attempt on a virgin system, before making a new release public.
  10. Hello Ameya Vikram Singh , this issue really makes me crazy. I am compiling SystemC from source. (I made a clean build, both for SystemC and my own app) I do have in the main CMakeLists file the line set (CMAKE_CXX_STANDARD 14 CACHE STRING "C++ standard to build all targets. Supported values are 98, 11, and 14.") I make ../configure, too. When I make the build, I receive tons of absolutely obsolete messages, but I cannot find out this crucial parameter: which standard was finally utilized? BTW: why? And why today a 20-years old standard is the default? What else shall I do to compile for standard other than the default? Why it is an issue for 2.3.>1, while it is not for 2.3.1, which I can install with no problem? ( I mean to build it together with libraries like gtest and Qt) Is there any option to build in the same way as 2.3.1? Is it only me who uses also another libraries in combination with SystemC? I make two debug prints in my root CMakeLists file, it says My C++ standard is ;98 Despite that I have changed to 14. Also, in my application directory My C++ standard is ;98 It looks like I cannot overwrite the default. What else shall I do? Is there any way to find out which standard uses a library I installed? Thanks for your help.
  11. Yes, probably you are right. But, I am finding SystemC in the root CMake file, and the printout comes from the leaf and it seems to be correct. BTW: what was the intention of with introducing such a degree of incompatibility with the compiler version? Was not enough the confusion with the different versions of the libraries? What if I use 6-8 different libraries with different (sometimes incompatible) versions per project, and now I must maintain also which version of which library was compiled with which standard?
  12. You know, in the makefile I use (as advised) set(CXXFLAGS -DCMAKE_CXX_STANDARD=${SystemC_CXX_STANDARD}) message("My C++ standard is " ${CMAKE_CXX_STANDARD}) The corresponding message on the screen is My C++ standard is ;98 Which is the default of the SystemC package. What else shall I do? The option in the main makefile mentions the incompatibility with TLM, but not any more potential issues.
  13. When I build my app with 2.3.3, I receive the error message in phase of linking: /usr/local/systemc/include/sysc/kernel/sc_ver.h:182: error: undefined reference to `sc_core::sc_api_version_2_3_3_cxx201103L<&sc_core::SC_DISABLE_VIRTUAL_BIND_UNDEFINED_>::sc_api_version_2_3_3_cxx201103L(sc_core::sc_writer_policy)' However, I am not (yet) using TLM, neither bind() in this simple test. What effect option "(DISABLE_VIRTUAL_BIND "Disable the definition of bind() member functions of ports and exports as \"virtual\", which is incompatible with old TLM library implementations (< 2.0.2)." OFF)" has? Shall I switch it on, or how otherwise can I eliminate its effect?
  14. Maybe you are right, but I have not yet seen "sensitive" in a loop. I am not used to that style, that is all. BTW: In this way the bits of a word are changed in a concurrent way. As the single bits from the submodules are connected individually to the bits of the word in the module, I guess there might not be any hazard in the electronic implementation. Also, as long as SystemC routines are executed in one thread, similarly no problem in the simulator. Am I right? In the future multithread versions of SystemC, may this change?
  15. You are right, but I have a high number of modules, and it is a very ugly code to be sensitive to so many signals. If my submodules (working concurrently) are manipulating sc_uint, I have synchronization issues.
×