Setting TOP variable does not set tcl scripts correctly
(1) By anonymous on 2021-06-04 20:27:58
Folks, Setting the TOP variable does not seem to ensure the top level directory is being set correctly for some (if not all) of the tcl scripts. I do not speak tcl, so In order to build sqlite from source I had to modify a couple of tcl scripts and build from the main directory. I commented out and hardcoded the 'topdir' variable at around line 12 in "sqlite\tool\mkshellc.tcl" tcl script and I also modified the "ext\fts5\tool\mkfts5c.tcl" tcl script by replacing "%dir%" in lines 7-22 with hardcoded paths for each file. Clearly this is not ideal; however, I do not know enough tcl to fix the issue myself. All I know is setting the TOP variable did not help! I compiled by running nmake in the top directory and not specifying the TOP variable: sqlite>nmake /f Makefile.msc Thanks!
(2.1) By Larry Brasfield (larrybr) on 2021-06-04 21:19:51 edited from 2.0 in reply to 1 [link]
You should not need to modify any TCL scripts. Here is an invocation that will build the amalgamation then the shell, provided it is run from a cmd.exe session that has had its environment set to make MSVC CLI tools usable:<code> cd \<top of SQLite source tree from sqlite.org\> md bld cd bld nmake /f ..\\Makefile.msc sqlite3.c TOP=.. nmake /f ..\\Makefile.msc sqlite3.exe TOP=.. </code>. Replace "\<top of SQLite source tree from sqlite.org\>" with the pathname which specifies the root of the retrieved SQLite library source tree.
(3) By anonymous on 2021-09-06 15:45:12 in reply to 2.1 [link]
I faced the same problem, and this instruction did not help solve the problem with TOP variable, and I get this error: couldn't open "./fts5.h": no such file or directory
(4.1) By Larry Brasfield (larrybr) on 2021-09-06 19:36:21 edited from 4.0 in reply to 3 [link]
I just demonstrated (to myself), again, that my above instruction alleviates any problem such as the OP (or you as 2nd anonymous) report. On the assumption that my instruction is not sufficiently clear, here is an elaboration: > You should not need to modify any TCL scripts. The demonstration runs successfully with a fresh, trunk checkout from the SQLite repository. By "fresh", I mean with all files as-is when fetched from the repo. > Here is an invocation that will build the amalgamation then the shell, provided it is run from a cmd.exe session that has had its environment set to make MSVC CLI tools usable: This means that one of the batch files installed along with Visual Studio in recent years, shortcut to which is labeled something like "Open Visual Studio 20xx Tools Command Prompt for targeting ..." and which resolves to running something like "...\\VC\\Auxiliary\\Build\\vcvars??.bat" in a cmd.exe session, has been run in a cmd.exe session. This leaves a number of environment variable set, such as INCLUDE, LIB, LIBPATH and PATH which makes the Microsoft Visual C/C++ command line tools (CL.exe, LINK.exe, LIB.exe, NMAKE.exe) conveniently usable. Moreover, the SQLite project makefiles for that toolset are designed with this setup presumed. > cd \<top of SQLite source tree from sqlite.org\> <br> md bld <br> cd bld <br> These steps create a directory to contain build products and intermediate objects that result from next step, and prepares to use it. This avoids cluttering the top-level checkout directory with a lot of extraneous stuff. Note that "\<top of SQLite source tree from sqlite.org\>" means the full pathname of the root of the retrieved SQLite library source tree, whether obtained from a compressed archive or opened (aka "checked out") from the project Fossil repository. A further preparation, (unmentioned earlier because the OP apparently did not still need to do it), is to arrange that the TCL shell, tclsh.exe, can be invoked from the cmd.exe session thusly:<code> tclsh ... </code>where ... is a set of arguments. There are alternatives, but the simplest is to arrange that %PATH% includes the bin subdirectory of a TCL installation. > nmake /f ..\\Makefile.msc sqlite3.c TOP=.. <br> nmake /f ..\\Makefile.msc sqlite3.exe TOP=.. These invocations will build (or copy) the named targets and required intermediate targets such as ./fts5.c and ./fts5.h . If we are to further discuss "the problem with the TOP variable", it would help to confirm that the above steps are being followed precisely.
(6) By anonymous on 2023-06-25 09:23:33 in reply to 4.1 [link]
For what it's worth, I had the exact same problem as the OP (building on Windows, following each steps carefully). Took me a while to figure out the problem was caused by a wrong tclsh.exe. In my setup, tclsh.exe was pointing to `msys64\usr\bin\tclsh.exe`. I don't know how that's compiled or where it comes from, the binary has no information, no version. I downloaded ActiveState's one, make sure it's first in the PATH, and now it works like a charm. (or I guess you can use the one in `msys64\mingw64\bin` as it's also marked as being compiled by ActiveState)
(7) By Keith Medcalf (kmedcalf) on 2023-06-25 15:55:27 in reply to 4.1 [link]
I have them side-by-each and it woks just fine. That is, the fossil "trunk" is `D:\Source\SQLite3` and the build directory is `D:\Source\bld` and I run `nmake -f ..\sqlite3\makefile.msc TOP=..\sqlite3 %MAKEOPTS% %1 %2 %3 %4 %5 %6 %7 %8 %9` in the `D:\Source\bld` directory.
(5) By J.M. Aranda (JMAranda) on 2021-09-06 19:23:29 in reply to 2.1 [link]
There are people who, faced with a good list of errors, go into panic mode and start editing like crazy. I recommend calm. Calm down, have a tea and ask here.