<shrit[m]>
is the build dir was empty when you executed this command?
<yugansharora01yu>
yes and it is still empty
<shrit[m]>
it can not still empty if you are facing an error
<shrit[m]>
See also "C:/dev/mlpack/mlpack/CMakeFiles/CMakeOutput.log".
<shrit[m]>
you are not executing the command from inside the build dir
<shrit[m]>
You need to clean the older build because cmake is caching
<yugansharora01yu>
i just deleted that whole mlpack folder and did everything again . Now i have cmakecache file in build directory after getting the same error
<yugansharora01yu>
it is the same error that occured previously 😟(((
<rcurtin[m]>
yugansharora01 (yugansharora01): it may be worth deleting the build directory to make sure that you are starting from nothing; if you've already run CMake before with other configuration variables set, the behavior could be not what you expect
<heisenbuugGopiMT>
Although you installed BLAS and LAPACK, you still need to specify it's path..
<yugansharora01yu>
i installed openBLAS
<heisenbuugGopiMT>
And I would suggest follow keon's blog, it's the easiest way on windows.
<yugansharora01yu>
and how to give its path?
<yugansharora01yu>
i did that almost everytime
<heisenbuugGopiMT>
Give me one sec...
<rcurtin[m]>
I'm not seeing the autodownloader even run in the output you gave. you need to use the git master branch in order for the autodownloader to work
<heisenbuugGopiMT>
I would suggest using the master branch and following keno's steps...
<heisenbuugGopiMT>
<heisenbuugGopiMT>
Tell me the error there...
<yugansharora01yu>
you know what this file was there tomorrow when i used visual studio nuget manager
<yugansharora01yu>
> I would suggest using the master branch and following keno's steps...
<yugansharora01yu>
>
<yugansharora01yu>
ok
<heisenbuugGopiMT>
Only follow step 1 and 2
<heisenbuugGopiMT>
> you know what this file was there tomorrow when i used visual studio nuget manager
<heisenbuugGopiMT>
Nope
<yugansharora01yu>
> > you know what this file was there tomorrow when i used visual studio nuget manager
<yugansharora01yu>
>
<yugansharora01yu>
> Nope
<yugansharora01yu>
i'm sure the openblas.dll.a file was there in mlpack/packages/openBLAS/something
<yugansharora01yu>
i used it to build armadillo
<heisenbuugGopiMT>
What was the error there then?
<yugansharora01yu>
but nvm i'm gonna use that blog steps now
<heisenbuugGopiMT>
And do it with master version
<yugansharora01yu>
> What was the error there then?
<yugansharora01yu>
when i started the compiling of mlpack code
<yugansharora01yu>
ok
<yugansharora01yu>
> And do it with master version
<heisenbuugGopiMT>
Okay, I think we can solve that...
<heisenbuugGopiMT>
Follow the steps in the blog and lets see
<yugansharora01yu>
> Okay, I think we can solve that...
<yugansharora01yu>
just one thing at what time i can find you here tomorrow?
<yugansharora01yu>
@heisenbuug should i follow all the steps given in the blog?
<heisenbuugGopiMT>
Yup
<heisenbuugGopiMT>
Message anytime, I will be active mostly...
texasmusicinstru has quit [Remote host closed the connection]
texasmusicinstru has joined #mlpack
<rcurtin[m]>
I won't be able to join the video call until 30 minutes in... it seems like the time is pretty bad for me, maybe we can consider an alternative if it's not a great time for others too? 😄
<heisenbuugGopiMT>
Okayyy, you tried that command? Did it start the build atleast?
<yugansharora01yu>
i don't think it downloads openblas it didn't do it in my case
<zoq[m]1>
I mean now we end up in the same situation as before, where we manually set the path.
<yugansharora01yu>
it has generated all the file and visual studio solution
<yugansharora01yu>
without errors
<heisenbuugGopiMT>
Actually long time ago when I followed Keon's blog, I was able to compile mlpack although it was tedious but it worked...
<heisenbuugGopiMT>
I might boot to windows after a long time for this...
<shrit[m]>
non, the autodownloader does not download blas, we have discussed that in the past
<shrit[m]>
the reason for this is that blas and openblas are not headeronly
<heisenbuugGopiMT>
okay, lets compile and see what happens...
<shrit[m]>
@zoq they are only downloaded when cross-compiling otherwise it does not download openblas, because it requires a compilation step
<heisenbuugGopiMT>
And hench I thought that maybe handle those 2 by Keon's method and leave rest for the auto-downloader, might work...
<zoq[m]1>
shrit[m]: but armadillo comes with blas/openblas dll for windows so there is no compilation step required, if you don't cross-compile.
<shrit[m]>
Even if it is downloaded from source?
<shrit[m]>
btw, why no one has joined today, meeting canceled?
<zoq[m]1>
We moved it to one hour later.
<zoq[m]1>
Because it clashes with Ryan's and my schedule as well.
<rcurtin[m]>
maybe should I send an email to the list to try and find a new time?
<rcurtin[m]>
or I could just propose 1800 UTC instead of 1700, and invite people to send a response if that is worse for them or something
<zoq[m]1>
rcurtin[m]: sounds good
<zoq[m]1>
<shrit[m]> "Even if it is downloaded from..." <- I think on Windows we don't have to compile the source, we already have the dll as part of the armadillo package.
texasmusicinstru has quit [Remote host closed the connection]
<heisenbuugGopiMT>
Are we meeting in 5 mins?
<zoq[m]1>
I think so.
<heisenbuugGopiMT>
okayyy
<SuvarshaChennare>
while going through the file src/mlpack/tests/cv_test.cpp
CaCode- has quit [Remote host closed the connection]
CaCode- has joined #mlpack
CaCode- is now known as CaCode
CaCode has quit [Remote host closed the connection]
texasmusicinstru has joined #mlpack
texasmusicinstru has quit [Remote host closed the connection]
texasmusicinstru has joined #mlpack
<rcurtin[m]>
https://github.com/mlpack/mlpack.org/pull/56 should be a quick review if anyone doesn't mind taking a look... it should hopefully fix the mlpack-git documentation on the website
texasmusicinstru has quit [Remote host closed the connection]
texasmusicinstru has joined #mlpack
<shrit[m]>
rcurtin: done 👍️
<rcurtin[m]>
thanks!
texasmusicinstru has quit [Remote host closed the connection]
texasmusicinstru has joined #mlpack
<shrit[m]>
okay, so the ensmallen FindAramdillo.cmake is doing the same as the one in mlpack, however it is written for the modern cmake configuration I suppose
<shrit[m]>
since the ensmallen is using `target_link_libraries` to link with arma
<rcurtin[m]>
I thought a bit more; I think both are derived from the version distributed with CMake, except it does a lot extra to find dependencies of Armadillo if `ARMA_USE_WRAPPER` is not set
<shrit[m]>
I need to find a way to make it work with the way the cross compilation set the libraries after finding them, I also do not want to modify the FindArmadillo provided with ensmallen
<rcurtin[m]>
it might be better to have just one version between mlpack and ensmallen? so maybe it is worth trying and taking the one from mlpack (which will already work ok for cross-compilation I guess?)
<rcurtin[m]>
I guess that cross-compilation for ensmallen is only useful for the tests, because it is header-only?
<zoq[m]1>
I think I'm missing something but are we going to modify the CMake config?
<shrit[m]>
Yeah, only for the tests
<shrit[m]>
in order to avoid compile the library on small devices
<shrit[m]>
also it will open the door for ensmallen uses to tests their code on any tiny device
<shrit[m]>
without the need to use mlpack with it
<shrit[m]>
Also I am not sure of modifying the cmake code in ensmallen
<zoq[m]1>
But as as rcurtin already pointed out ensmallen is header only.
texasmusicinstru has quit [Remote host closed the connection]
<zoq[m]1>
I don't expect anyone to cross-compile the test executable, I mean why would someone do that?
<shrit[m]>
in order to avoid compile them on a raspberry pi
<shrit[m]>
so you will gain sometime during the day
<shrit[m]>
and the device will note suffer as well
<shrit[m]>
but if it too complex I can drop the idea
texasmusicinstru has joined #mlpack
<zoq[m]1>
I mean, I still don't see why someone would build the test executable on a rpi, it's not that the executable provides any functionality like the mlpack executables.
<rcurtin[m]>
personally it seems like a really niche use case, but I'm not necessarily opposed to it; with a header-only library, it feels like a user should be able to use CMake's existing cross-compilation support
<zoq[m]1>
At least from my side I like to keep the CMake file simple.
<rcurtin[m]>
it seems like it could be possible to check the cross-compilation support while keeping things simple... e.g., maybe we could just add some documentation for users who want to cross-compile some ensmallen code? (and maybe some bugfixes for our CMake configuration in case it doesn't work when cross-compiling)
<rcurtin[m]>
when we added cross-compilation support to mlpack, I think most of the work was just getting the right OpenBLAS dependency in place---I think the actual changes we made to the main mlpack CMake configuration were really minimal, if I remember right
<zoq[m]1>
But I wouldn't use the ensmallen CMake file in my project.
<rcurtin[m]>
hmm, true
<rcurtin[m]>
we could at least add documentation to point a user towards mlpack's autodownloader/OpenBLAS builder perhaps? I'm not sure
<rcurtin[m]>
(I think I've only ever cross-compiled something once or twice, so I may not have the best insight here)