hkaiser changed the topic of #ste||ar to: STE||AR: Systems Technology, Emergent Parallelism, and Algorithm Research | stellar.cct.lsu.edu | HPX: A cure for performance impaired parallel applications | github.com/STEllAR-GROUP/hpx | Buildbot: http://rostam.cct.lsu.edu/ | Log: http://irclog.cct.lsu.edu/
hkaiser has quit [Quit: bye]
K-ballo has quit [Quit: K-ballo]
quaz0r has quit [Ping timeout: 246 seconds]
quaz0r has joined #ste||ar
nikunj97 has joined #ste||ar
K-ballo has joined #ste||ar
hkaiser has joined #ste||ar
<hkaiser> simbergm: I pushed a commit fixing the source groups directly to your branch, hope you don't mind
<simbergm> hkaiser: not at all
<simbergm> seems you already noticed I left out the set_target_property calls, sorry about that
<simbergm> if this works then we go with this
<simbergm> I'm not happy that the sources have to go to add_library, but that seemed to be a requirement, no?
<K-ballo> it is not a cmake requirement
<hkaiser> K-ballo: it's needed for source groups to work
<K-ballo> no, it isn't
<hkaiser> well, it didn't wrk without it
<K-ballo> without it as in not adding sources to the target in any other way?
<hkaiser> yes
<K-ballo> well sure, only a target's sources are sources of a target
<hkaiser> not sure if there is another way
<K-ballo> but that does not require passing the sources to add_library
<K-ballo> there's set_target_sources or similar
<hkaiser> what other way would we have?
<K-ballo> I usually glob headers and add them to source groups that way
<hkaiser> K-ballo: ok, I'll try that
<K-ballo> I don't know how this relates to hpx's own cmake framework, or if it is relevant at all there
<hkaiser> simbergm: do we add our module targets as dependencies to libhpx?
<hkaiser> where is that done?
<simbergm> it's definitely not required for correct compilation, setting targets as dependencies will do the right thing
<simbergm> sec
<simbergm> hkaiser ^
<hkaiser> : ahh, ok
<simbergm> I'm wondering if cmake is going to recompile cpp files when they're added like that
<simbergm> most likely it will
<hkaiser> in that case we don't need a custom property, do we?
<simbergm> and the modules will be for nothing :/
<simbergm> I couldn't figure out a way to get sources and headers in a way that cmake doesn't complain
<simbergm> on an INTERFACE target get_target_property(target PROPERTY SOURCES) gave me an error (no SOURCES on an INTERFACE library)
<simbergm> thought this was the cleares
<simbergm> t
<hkaiser> simbergm: also, target_sources does not allow to distinguish headers and source files
<simbergm> but maybe there is some property for getting all that information out
<hkaiser> we might need both
<K-ballo> simbergm: INTERFACE targets only have INTERFACE properties
<simbergm> yep
<hkaiser> target_sources and our own property holding the list of headers/source files
<K-ballo> why not just set INTERFACE_SOURCES, if the intent is to propagate them
<simbergm> yeah, it makes sense, just not that it needs to error out on it
<hkaiser> K-ballo: sure, but that mixes headers and sources file, so we still need our own property
<K-ballo> what do we need our own property for?
<simbergm> K-ballo: sure if CMake doesn't do anything else with it?
<K-ballo> simbergm: cmake will transitively add the sources to anyone that links on said target, as with any other interface property
<simbergm> right, so INTERFACE_SOURCES is most likely already set after we've done add_library(target sources headers)?
<hkaiser> K-ballo: I'm seeing 'CMake Error in libs/preprocessor/CMakeLists.txt:
<hkaiser> Target "hpx_preprocessor" INTERFACE_SOURCES property contains path:'
<simbergm> but if we need to distinguish between the two then that's not enough
<hkaiser> I don't know what I'm doing here ;-)
<hkaiser> simbergm: I'll leave it to you, you have my changes ...
<hkaiser> feel free to change it
<K-ballo> sure, sources will be set when the initial source of the target are set
<K-ballo> subsequent calls append to it
<simbergm> we can even leave the targets alone and just define separate variables for this
<simbergm> it's purely internal
<simbergm> and ugly in any case
<K-ballo> target_sources(foo INTERFACE headers)
<K-ballo> that reminds me target_sources had a bug until recently that failed to evaluate relative paths at invocation time
<hkaiser> simbergm: but that's what I've done - or did you have something else in mind?
<simbergm> hkaiser: nono, I'm agreeing with you
<simbergm> I know no more
<simbergm> but this works for you, right? and you need sources and headers to be added as separate source groups? that's the requirement?
<simbergm> and it doesn't work unless you add them in add_library(hpx ...)?
<simbergm> if that's it then I don't have any better ideas
<hkaiser> sources need to somehow be associated with the target
<K-ballo> adding them in target_sources(...) works just as fine
<simbergm> and btw, thanks hkaiser! :)
<hkaiser> not sure if this can be done differently
<hkaiser> simbergm: and yes, I'd like to have separate source groups for headers and source files
<simbergm> then this will have to do
<simbergm> K-ballo: is add_library(target sources) not equivalent to later saying target_sources(target sources)?
<K-ballo> maybe? strictly speaking, no
<K-ballo> add_library(target source1 source2 source3) is equivalent to add_library(target) target_sources(target source1 source2) target_sources(source3), except
<K-ballo> except that add_library(target) with no sources whatsoever was rejected until 3.8 or so
<simbergm> grr, ok, close enough
<simbergm> I'm still worried we'll be source files from modules twice like this
<simbergm> *we'll be compiling
<K-ballo> we would if the sources are PUBLIC/INTERFACE
<K-ballo> and "compilable" of course
<K-ballo> what kind of target is a "module"
<simbergm> cpp files that is
* K-ballo really didn't wanted to learn more about hpx's own cmakeisms
<simbergm> "module" is just what we happen to call our little libraries that we'll be breaking out
<simbergm> "library"
<simbergm> "sub-project"
<K-ballo> sure, and what kind of cmake target represents that?
<simbergm> not sure what to call them
<K-ballo> that's an interface library target
<simbergm> that one exactly
<simbergm> we'll have ones that will be compiled as well later on
<K-ballo> would those still be interface? or static libraries?
<simbergm> K-ballo: static libraries
<K-ballo> static libraries would get their own vs project, where the corresponding sources and source groups would appear
<K-ballo> those sources would not be in the interface, would not propagate to other targets
<hkaiser> simbergm: should we really compile the modules into their own libraries?
<simbergm> hkaiser: yes! unless I'm misunderstanding you we definitely want separate libraries
<simbergm> that's what we get with add_library
<simbergm> hkaiser: yes! I don't see why not
<simbergm> Currently they would just get statically linked to the main hpx library but they could (can already actually) be consumed individually by e.g. some non hpx tests and external projects could do the same if they don't want all of hpx
<simbergm> Currently they would just get statically linked to the main hpx library but they could (can already actually) be consumed individually by e.g. some non hpx tests and external projects could do the same if they don't want all of hpx
<simbergm> sorry about the duplicates... hope it makes sense anywya
<hkaiser> simbergm: nod, ok
<hkaiser> in that case those libraries would become separate VS projects (as K-ballo said)
<hkaiser> not sure if we could create VS projects using cmake that don't have source files (we might have to add empty source files for this to happen)
<simbergm> hkaiser they'd still have header files
<hkaiser> in this case the source groups would be local to those VS projects and we wouldn't need to add the sources to the main hpx projetc anymore
<hkaiser> simbergm: I know
<simbergm> Right, I think that was the original intention
<hkaiser> there is no way to let cmake create a VS project that doesn't have source files, IIRC
<hkaiser> ok, so let's add an empty source file (if needed for VS only) and create separate static libraries
<simbergm> Bleh, so that's why you weren't seeing them
<hkaiser> right
<hkaiser> misunderstanding on my part, I guess - sorry
<simbergm> Not sure it won't create a dummy empty library as well then
<simbergm> No worries, I was equally confused
<hkaiser> simbergm: yah, it would create an empty library - so what?
<simbergm> Just ugly, that's all
<hkaiser> we can do that for VS projects only
<simbergm> Ok, sure
<hkaiser> let me try that
<simbergm> Sure, thanks
<hkaiser> simbergm: in this case the add_library(hpx_pp...) can't be just INTERFACE only anymore
<hkaiser> simbergm: https://imgur.com/a/KWLwbh8 \o/
<simbergm> !
<simbergm> thanks hkaiser!
<heller> simbergm: cmake generates build files that recompile if needed
<heller> if a targets cpp file changes, dependencies merely get relinked
<heller> that's one big advantage here
<simbergm> heller: sure, that's the case with a single huge library as well
<heller> ok, I guess I missed the point ;)
<simbergm> I don't know what we're arguing about anymore... :P
<simbergm> hkaiser: we might need to still make it an interface library for non-msvc, or just include the cpp file always to avoid this
<hkaiser> simbergm: sure, please change whatever you think is needed
<simbergm> good, I'll take care of it
nikunj97 has quit [Remote host closed the connection]