-
Notifications
You must be signed in to change notification settings - Fork 60
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update boost deps for core and mss, track Sparta PR397 #42
Conversation
Ok, step 1 complete: MAP PR merged: sparcians/map#397 |
Now to get this regressing! |
@knute-sifive any objections if we move cmake version required forward to 3.19 or more recent? Right now we use 3.17 here, but that does not yet define the catch-all HDF5::HDF5 target, which was introduced in 3.19. And that breaks the build here. For reference: Sparta uses 3.26 in CI, but the cmake files say min = 3.15, so that's also wrong (I'll file a quick PR for that in spara repo as well) Over here, I'll update the conda environment file with a more recent version and push that, but I am not sure if this will automatically update the image on which CI runs, I might need your help for that. |
@knute-sifive I'm kind of stuck at this point: I have the HDF5 issue fixed, but with the CI pinned to sparta v1.1.1 this won't be able to pass... Any advice? I don't want to break master CI either. Also the conda environment.yml had everything pinned to exact versions, and pushing cmake to a newer version created an avalanche of dependent version changes. I've changed all =version lines to >=version. So this might have some unintended side effects too... |
Glad you are looking into that - that’s too much magic for me ;) |
Huzzah! |
Hey Peter, update your clone and see if a release and/or debug build works for you. |
core/CMakeLists.txt
Outdated
@@ -20,5 +20,3 @@ add_library(core | |||
CPUFactory.cpp | |||
CPUTopology.cpp | |||
) | |||
target_include_directories(core SYSTEM PRIVATE ${Boost_INCLUDE_DIRS}) | |||
target_link_libraries(core PUBLIC SPARTA::sparta) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since I don't do a conda install of sparta, this fails for me: sparta include paths and link paths are not passed properly.
I had to put back a few target_link_libraries to find sparta (I don't have it installed in conda env so it's not picked up automatically in the default paths). Since that does not break CI, this looks good to go to me, but it could do with a review especially to check:
|
That's so weird that's required for the core library build. Curious -- what didn't link? The issue I have with adding sparta as a link library is that I believe this causes the core archive to blow up in size. I think.
I don't see problem with that. Probably should use an stf tag and tag Mavis so we have consistency and not some random SHA. I'll look into that on the next revision. Updating the yaml file for Conda is fine -- the CI uses it, so if it passes, then it should good to go! |
2 similar comments
That's so weird that's required for the core library build. Curious -- what didn't link? The issue I have with adding sparta as a link library is that I believe this causes the core archive to blow up in size. I think.
I don't see problem with that. Probably should use an stf tag and tag Mavis so we have consistency and not some random SHA. I'll look into that on the next revision. Updating the yaml file for Conda is fine -- the CI uses it, so if it passes, then it should good to go! |
That's so weird that's required for the core library build. Curious -- what didn't link? The issue I have with adding sparta as a link library is that I believe this causes the core archive to blow up in size. I think.
I don't see problem with that. Probably should use an stf tag and tag Mavis so we have consistency and not some random SHA. I'll look into that on the next revision. Updating the yaml file for Conda is fine -- the CI uses it, so if it passes, then it should good to go! |
But don't all those core units depend on Sparta? I get the errors during compile on missing includes, not on linking:
|
I added Since it's all statically linked at the end, I guess it could be sufficient to just add the includes here? |
CMakeLists.txt
Outdated
else() | ||
message (STATUS "Sparta was found in ${SPARTA_SEARCH_DIR}") | ||
endif() | ||
#include_directories(${SPARTA_INCLUDE_DIRS}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm wondering if uncommenting this line will fix your include issues. Can you do that AND remove the target_link lines to see if you still have problems?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It helps to some extent: No more errors on Sparta includes, but it lacks the secondary includes it seems, as now I am getting boost errors: (which on my system is also not in a default system path, because I am pointing to a specific version somewhere in /opt/homebrew
)
(which ironically is back to square one - not finding boost was my initial problem to tackle all makefiles ;-) )
In file included from /Users/pdback/src/peter-d/riscv-perf-model/core/Decode.cpp:6:
In file included from /Users/pdback/src/peter-d/riscv-perf-model/core/Decode.hpp:8:
In file included from /Users/pdback/opt/sparta/include/sparta/ports/DataPort.hpp:15:
In file included from /Users/pdback/opt/sparta/include/sparta/ports/Port.hpp:19:
In file included from /Users/pdback/opt/sparta/include/sparta/events/Event.hpp:15:
In file included from /Users/pdback/opt/sparta/include/sparta/events/EventNode.hpp:16:
In file included from /Users/pdback/opt/sparta/include/sparta/simulation/Clock.hpp:21:
/Users/pdback/opt/sparta/include/sparta/kernel/Scheduler.hpp:13:10: fatal error: 'boost/timer/timer.hpp' file not found
#include <boost/timer/timer.hpp>
^~~~~~~~~~~~~~~~~~~~~~~
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's what this line and the next in FindSparta.cmake
are providing automatically when you add sparta as a link library:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I can reproduce the missing include problem, but the not boost one. I'll admit that I don't fully grok how cmake
brings in the goods from a package. You'd think the find_package
method would be enough! But sparta must be installed in a "standard" location or something so that includes AND library paths are set up? I don't get it...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All find_package
does is import a target for the library (as if it were defined elsewhere in the makefiles with add_library
) but it won’t set up any default compile or link flags project wide, it will only add the relevant options to the targets when you explicitly say they depend on the imported target. In this case that means unless you explicitly add SPARTA::sparta it won’t pass the flags. Which you won’t notice if everything is installed in system wide include and lib paths, but it will break as soon as one of the components (either Sparta or the lobs it depends on) is not in that default path.
That said, there could be a way to only add the include paths and maybe not the link flags, but I expect that to fail at linking still…
Reason I see boost problems is because I have multiple boost versions via homebrew, and Sparta needs one that is not the default one. (There’s macOS issues with boost 1.81 command line arguments)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you Peter and Knute for working through this.
Trying to understand the latest status of this work: From the comments above, I understand at least the regression is not working yet. But is it just the regression or more than that? Would I be able to build riscv-perf-model / olympia with latest head of master of Sparta (which installs Sparta in the conda environment)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually regression is working with these changes, but only because the CI is strictly controlled:
- Create a conda environment
- Build and regress everything inside that conda environment
For those folks that do not use conda or prefer not to, it's hard to set up a CMakeList flow that works for both.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As long as Sparta (and it’s dependencies like boost hdf5 etc) are available in the default paths (libs and includes) it just works. It’s just in case some dependencies are not in a default location, that the overridden paths are not passed through from Sparta to Olympia… (eg I have a home brew boost version in macOS that is not the default one which gives me troubles when I want to this locally branch)
@knute-sifive so just so I fully get this what's the intended goal in the end? And why is it not ok to tell cmake that Olympia links against sparta? As far as I understand:
In order to be able to compile Olympia objects that use Sparta, the include paths to Sparta need to be set up correctly, of course. Possibly also those of dependent libs? (I haven't checked if Sparta header files include header files from its dependencies, but it's likely at least some do) Then at link time, we need to point Olympia to the Sparta static lib Then I don't really see why it would be bad to just include the |
So, adding I was stuck on this for the past week until I chatted with @bdutro about what we think I think we understand now. In the main
which brings in Sparta libraries and includes for just Olympia and not the libraries. However, I think if you add this line to the top level
Can you try this (and remove the |
So this didn't work right away and I haven't had time to check this further until today.
Which means there's really not much that needs changing here, but I'll need to fix the FindSparta.cmake once more. |
Signed-off-by: Peter Debacker <[email protected]>
@knute-sifive if you could review? |
Absolutely! Yes, let's get this in by the weekend. |
Updated with map_v2.0 notes Signed-off-by: Knute Lingaard <[email protected]>
This fixes #35 and tracks the changes in Sparta PR397