(1) I have a LARGE filebase with around 70,000 files, many of them are NightOwl
Shareware CDS, which have screwed up FILES.BBS so I had CASE issues with
everyone of them, the FILES.BBS showed the files in uppercase, while the
files were actually stored in lowercase. I thought maybe SBBS would have
ignored this, or fixed it, since it has now became such a smart software
suite, but it did'nt. it showed every one of these files offline until
I hacked up a commandline that recursivly dove into all the sub directorys
and renamed all the files to uppercase. Maybe it's something I missed,
i would like to point it at a directory, and have it create the file areas , spaces or not in the name (in my case it's bbs.mods,etc) , but things arent working well. it would also be nice to import sub dirs within directories.
i have to manually create the areas to make sure things are
setup correctly.
Re: Some questions and general comments for the Devel team.
By: Mro to KK4QBN on Tue May 23 2017 19:35:09
i would like to point it at a directory, and have it create the file areas , spaces or not in the name (in my case it's bbs.mods,etc) , but things arent working well. it would also be nice to import sub dirs within directories.
i have to manually create the areas to make sure things are
setup correctly.
It was simple enough to get them going under the windows machine, I did have to put a lot of work in though to name the file areas, there were no files on the original cds that I could quickly import that from, so I did a dir import of each and every CD and then manually cut and pasted file area names
With that being said I will go ahead and post some of the questions/comments I had all in one message, and it all should be on topic in this area.
My BBS grew so quick that I had to move from the old XP box I was running it on to a faster machine, I moved it to a linux system and I want to say, the transition could'nt have been easier. Of course I ran into a couple issues but those were pretty much my fault to an extent:
(1) I have a LARGE filebase with around 70,000 files, many of them are NightOwl
Shareware CDS, which have screwed up FILES.BBS so I had CASE issues with
everyone of them, the FILES.BBS showed the files in uppercase, while the
files were actually stored in lowercase. I thought maybe SBBS would have
ignored this, or fixed it, since it has now became such a smart software
suite, but it did'nt. it showed every one of these files offline until
I hacked up a commandline that recursivly dove into all the sub directorys
and renamed all the files to uppercase. Maybe it's something I missed, but
if it is'nt, could this be something to put into a future version of SBBS?
it would'nt have been an issue if the idiots at NightOwl would have left
the file_id.diz or desc.sdi in the files, then I could have done just a
straight import. I do realize I could have changed the case in the actual
files.bbs too, but it was just easier doing the files themselves.
Alright, here is my next issue, I have NEVER been able to get the linux native version of SBL working. I'm able to catch the output and it was stating that I need to set the SBBSNODE env var, I did that. It no longer gives me that error, but now it just does'nt work. and that was with how it came installed stock from the CVS repo, all I did was freshly build sbl and make sure the symlinks worked. and they do. it kinda makes me wonder if smb2sbl and sbl2smb is even working? I've never noticed any errors around the time they run on event.
Which brings be to futureproofing. how far away is /sbbs/exec/sbbslist.js from being complete, or is it already?
from what I can see it should at
least work as an sbl viewer, editor, but I lack the abstract though to know what commandline arguments to pass to it, and I see that helfile that the app states should reside under ../text does not exist on either my local file system or the CVS repo, so obviously this is still under construction.
Since I'm having these issues with the linux native version of SBL, and sooner or later SBBS will moving to this script to do ALL the sbl work, I would like to go ahead and get it in operation, if it is close enough to do that.
I've been up and down the JS and cannot find what arguments to pass to the JS to make it work, I'm just attempting to fire up SBL only and I get this error:
Loading configuration files from /sbbs/ctrl/
JavaScript-C 1.8.5 2011-03-31
JavaScript: Creating runtime: 8388608 bytes
JavaScript: Initializing context (stack: 16384 bytes)
Reading script from /home/sbbs/sbbs/exec/sbbslist.js /home/sbbs/sbbs/exec/sbbslist.js compiled in 0.02 seconds
!JavaScript /home/sbbs/sbbs/exec/sbbslist.js line 29: TypeError: options is null
Re: Some questions and general comments for the Devel team.
By: KK4QBN to Mro on Tue May 23 2017 09:15 pm
Re: Some questions and general comments for the Devel team.
By: Mro to KK4QBN on Tue May 23 2017 19:35:09
i would like to point it at a directory, and have it create the file areas , spaces or not in the name (in my case it's bbs.mods,etc) , but things arent working well. it would also be nice to import sub dirs within directories.
i have to manually create the areas to make sure things are
setup correctly.
It was simple enough to get them going under the windows machine, I did have to put a lot of work in though to name the file areas, there were no files on the original cds that I could quickly import that from, so I did a dir import of each and every CD and then manually cut and pasted file area names
bbs.cracks
bbs.doorgames.cheepware
bbs.doorgames.food
bbs.doorgames.lord
bbs.doorgames.lunatix
bbs.doorgames.sorted.0-9
bbs.doorgames.sorted.a-h
bbs.doorgames.sorted.i-p
bbs.doorgames.sorted.q-z
bbs.doorgames.t1ny
bbs.doorgames.topcop
bbs.doorgames.tradewars
bbs.doorgames.TXDS
bbs.doorgames.usurper
bbs.mods
bbs.related
bbs.software.bbbs
bbs.software.c64bbs
bbs.software.elebbs
bbs.software.EZYCOM
bbs.software.gap
bbs.software.hermes
bbs.software.illusion.bbs
bbs.software.iniq
bbs.software.maximus
bbs.software.mbbs
bbs.software.mystic
bbs.software.PCBOARD
bbs.software.RA
bbs.software.rg
bbs.software.searchlight
bbs.software.software.bbsdocumentary.com
bbs.software.SPITFIRE
bbs.software.synch
bbs.software.telegard
bbs.software.tribbs
bbs.software.unsorted
bbs.software.vadv
bbs.software.WILDCAT
bbs.software.worldgroup
bbs.software.WWIV
bbs.sourcecode
bbs.unsorted
bbs.utils
bbs.vids
^^^ this is how my directories are named and it wont import the file areas correctly.
Since Windows file systems are case-insensitive, that would "just work" there. But on Linux, the file systems are case sensitive, so it would take some special logic to perform case-insensitive searches and some sysops may not want that change in behavior. Though, really, who in their right mind would want both README.TXT and ReadMe.txt (as 2 differnet files) in the same directory is beyond me.
Firstly, Synchronet itself sets the SBBSNODE env. var before spawning external programs (e.g. doors, including SBL) - so that is weird. You should not need to set SBBSNODE to get doors to work. I do recall that there's a shell script (xtrn/sbl/sbl) which spawns the correct build for that local system: http://cvs.synchro.net/cgi-bin/viewcvs.cgi/xtrn/sbl/sbl?view=log
Which brings be to futureproofing. how far away is
/sbbs/exec/sbbslist.js from being complete, or is it already?
Probably 75%.
Loading configuration files from /sbbs/ctrl/I was sitting on some local changes to sbbslist.js including the fix for that one (when there's no [sbbslist] section in the modopts.ini), so I'll go ahead and commit those changes now.
JavaScript-C 1.8.5 2011-03-31
JavaScript: Creating runtime: 8388608 bytes
JavaScript: Initializing context (stack: 16384 bytes)
!JavaScript /home/sbbs/sbbs/exec/sbbslist.js line 29: TypeError:
options is null
The main feature missing right now is adding a new BBS entry. So, that's a pretty big one. :-)
Re: Some questions and general comments for the Devel team.
By: Digital Man to KK4QBN on Sat Jun 03 2017 14:36:24
Since Windows file systems are case-insensitive, that would "just work" there. But on Linux, the file systems are case sensitive, so it would take some special logic to perform case-insensitive searches and some sysops may not want that change in behavior. Though, really, who in their right mind would want both README.TXT and ReadMe.txt (as 2 differnet files) in the same directory is beyond me.
I understand that completely, mainly, the issue with importing the shareware CDS is the the files.bbs listed the files as UPPER case and the files were lower case on the local file system. addfiles imported the files and areas fine, but when someone actually tried to download it would show the file as offline. I've got most of it fixed now either by changing the files.bbs or changing the case of the filenames, depending on what needed to be done for each cd. took a little more work, but was'nt too bad.
Firstly, Synchronet itself sets the SBBSNODE env. var before spawning external programs (e.g. doors, including SBL) - so that is weird. You should not need to set SBBSNODE to get doors to work. I do recall that there's a shell script (xtrn/sbl/sbl) which spawns the correct build for that local system: http://cvs.synchro.net/cgi-bin/viewcvs.cgi/xtrn/sbl/sbl?view=log
Wow, yeah.. that is strange..
this was with a sbl that was built on this
machine from the cvs sourcecode so, yeah I don't quite understand it. even when I set the SBBSNODE var, it still will not execute.
I'm at a loss, I
truly cannot figure out whats going on. I've never had issues with it before. I also tried download prebuilt versions of it, still no go.
it will
run from the cli but I receive this error:
!XSDK Error -1 (88) sending on socket 0
!XSDK Error -1 (88) sending on socket 0
* 12
but when I try to run from the BBS it just passes a blank screen and goes straight back to the BBS.
As it turns out, the case indifference/correction was *mostly* there (for *nix builds), except for one key spot. So you could list the files and they wouldn't show as blinking red with a '-' next to the file (as if they were online) but you couldn't download them. That's now fixed.
Wow, yeah.. that is strange..So where are you setting the SBBSNODE env. var that it actually had any impact on this?
Where is the executable you're buidling being placed?
I wouldn't expect it to work from a *nix shell. Were you executing the shell script (xtrn/sbl) or the executable you built directly?
And how/where did you see an error related to the SBBSNODE env. var?
And how/where did you see an error related to the SBBSNODE env. var?
running the straight executable from the commandline (which I presume should happen).
I'll test the shell script and go from there.
bbs.sourcecode
bbs.unsorted
bbs.utils
bbs.vids
^^^ this is how my directories are named and it wont import the file areas correctly.
Can you elaborate - i.e. what is the error message and what program is failing to import?
If the directories are named with underscores instead of dots, do you see any difference in behavior?
Wow, yeah.. that is strange..So where are you setting the SBBSNODE env. var that it actually had any impact on this?
at first I set it in the terminal before running sbbs, sbl would run afterwards from the cli, but not the BBS, giving the error I showed earlier, then I set it in the .profile (and) .bashrc of the user sbbs. sbl is still running, giving the error on the cli, but not running from the bbs itself.
Where is the executable you're buidling being placed?
I have my sbbs filetree in the user (sbbs) homedir, then symlink to that filetree from the root incase there are issues, sbl resides in /sbbs/xtrn/sbl. (/home/sbbs/sbbs/xtrn/sbl).
I wouldn't expect it to work from a *nix shell. Were you executing the shell script (xtrn/sbl) or the executable you built directly?
the executable, I knew nothing of the shell script until you informed me, and I havent tested it yet.
And how/where did you see an error related to the SBBSNODE env. var?
running the straight executable from the commandline (which I presume should happen).
Re: Some questions and general comments for the Devel team.
By: KK4QBN to Digital Man on Sat Jun 03 2017 23:15:35
And how/where did you see an error related to the SBBSNODE env. var?
running the straight executable from the commandline (which I presume should happen).
I'll test the shell script and go from there.
Its still doing the same, acts as if it will run, then swaps back to the bbs.
I've tried running this on every single configuration I know, leaving the executables in their build directory, and trying them from ../xtrn/sbl dir. now with the shell script. just for kicks I tried the shell script from the cli and received the same XSDK error as earlier. but this time I had to ctrl-c out of it, it did'nt drop out on its own. but I'm still getting the same action running from the bbs as earlier.
I lost the default setting of how sbl is setup from cvs when I merged from windows, but I have set sbl up so many times I would have thought I would have it running by now :(
Re: Some questions and general comments for the Devel team.
By: Digital Man to Mro on Sat Jun 03 2017 03:22 pm
bbs.sourcecode
bbs.unsorted
bbs.utils
bbs.vids
^^^ this is how my directories are named and it wont import the file areas correctly.
Can you elaborate - i.e. what is the error message and what program is failing to import?
If the directories are named with underscores instead of dots, do you see any difference in behavior?
it's the scfg file area section. it just ends up importing a handful of the directories in, but no error msg.
i didnt experiment by changing directory names with underscores, but i can experiment later. i end up just typing it all in manually.
--edit--
this might be a windows only issue because i just did it with the same files and file structure on linux and it appears to be working.
Very odd. For one, Synchronet must set the SBBSNODE environment variable in the environment of the shell for the node on which the door is being run (e.g. /sbbs/node1 for Node #1 and /sbbs/node2 for Node #2). If any setting of SBBSNODE *before* Synchronet is run would have any effect, then all doors (that use that env var) would be sharing the same node directory regardless of which node ran the door, and that would not work.
When you build 'sbl', it normally places the executable in a sub-directory (e.g. off of xtrn/sbl). My question is, where is the 'sbl' that you built? If you type 'locate sbl' you should find multiple copies, or at least 2, one being the shell script at xtrn/sbl/sbl and another in a sub-directory off of xtrn/sbl. If you have more, that would be good to know too.
Is it possible you have multiple copies of sbl and the shell script (xtrn/sbl/sbl) is finding and executing the wrong one?
Here's the configuration I use which works, but I'm using a symlink to the sbl executable rather than the shell script:
Here's the configuration I use which works, but I'm using a symlink
to the sbl executable rather than the shell script:
this is almost what I have, I had it to write the xtrn.dat in lowercase, hopefully that is the issue. thanks for your help, I'll forge on from here and see if I can get it right..
Re: Some questions and general comments for the Devel team.
By: Digital Man to KK4QBN on Sun Jun 04 2017 03:38:25
Very odd. For one, Synchronet must set the SBBSNODE environment variable in the environment of the shell for the node on which the door is being run (e.g. /sbbs/node1 for Node #1 and /sbbs/node2 for Node #2). If any setting of SBBSNODE *before* Synchronet is run would have any effect, then all doors (that use that env var) would be sharing the same node directory regardless of which node ran the door, and that would not work.
I expected that, I don't understand though why sbl was asking for it to be set in the first place.
When you build 'sbl', it normally places the executable in a sub-directory (e.g. off of xtrn/sbl). My question is, where is the 'sbl' that you built? If you type 'locate sbl' you should find multiple copies, or at least 2, one being the shell script at xtrn/sbl/sbl and another in a sub-directory off of xtrn/sbl. If you have more, that would be good to know too.
it is in gcc.linux.x64.exe.debug under the sbl dir now that I have the script.
I've tried the executables both under the above mentioned dir, and also just copied them to /sbbs/xtrn/sbl with no luck.
wait.. I understand the sbbsnode issue now, the only action i'm getting from sbl at all is on the commandline, so if the bbs is'nt calling it the sbbsnode environment will not be set for that instance. which made me assume that was happening when tryig to run it from the bbs since I have no output to work with showing what is wrong. so that kills the sbbsnode issue (I presume).
It's possible I may have sabotaged my efforts from the beginning. I'm usually on node one when logging in. and thats what I had it set to, but I need to strip that out of my settings and try again.
Re: Some questions and general comments for the Devel team.
By: KK4QBN to Digital Man on Sun Jun 04 2017 07:24:33
Here's the configuration I use which works, but I'm using a symlink
to the sbl executable rather than the shell script:
this is almost what I have, I had it to write the xtrn.dat in lowercase, hopefully that is the issue. thanks for your help, I'll forge on from here and see if I can get it right..
and that was it.. more than likely case issues again, it would not work with the script for some reason, but works fine with a symlink.
--edit--
this might be a windows only issue because i just did it with the same files and file structure on linux and it appears to be working.
Or perhaps it was just a bug in an older version of SCFG?
it is in gcc.linux.x64.exe.debug under the sbl dir now that I have the
script.
Okay, and do the permissions look good (i.e. the user that the BBS runs as has read/execute permissions)?
Yes, I think that was it. Running SBL (or any XSDK door) outside of the BBS is not a good test. There are some other XSDK doors (SBJ, Domain Poker, Beast's Domain), do they work okay?
No, Synchronet will overwrite the environment variable when it spawns new processes (e.g. for doors), so the fact that you did set SBBSNODE before running sbbs should have no effect on 'sbbs' itself. Some older Synchronet utilities may still need/want the SBBSNODE environment variable to be set (to point to any of the node directories), so it's not bad to have it set but should make no difference in this case.
Okay, good to know. It could just be a bug in that script.
Re: Some questions and general comments for the Devel team.
By: Digital Man to Mro on Sun Jun 04 2017 03:41 am
--edit--
this might be a windows only issue because i just did it with the same files and file structure on linux and it appears to be working.
Or perhaps it was just a bug in an older version of SCFG?
i'm not running the absolute newest sbbs for windows but i have 3.17a running when i tried it again.
okay just tried it on my windows computer.
did import and chose no for recursive.
says it imported 33 directories, i only see 4 in the section in scfg
i have 42 directories in that dir that i am trying to import.
http://i.imgur.com/ezSR6cG.png
Re: Some questions and general comments for the Devel team.
By: Digital Man to Mro on Sun Jun 04 2017 03:41 am
--edit--
this might be a windows only issue because i just did it with the same files and file structure on linux and it appears to be working.
Or perhaps it was just a bug in an older version of SCFG?
i'm not running the absolute newest sbbs for windows but i have 3.17a running when i tried it again.
okay just tried it on my windows computer.
did import and chose no for recursive.
says it imported 33 directories, i only see 4 in the section in scfg
i have 42 directories in that dir that i am trying to import.
http://i.imgur.com/ezSR6cG.png
Re: Some questions and general comments for the Devel team.
By: Digital Man to KK4QBN on Sun Jun 04 2017 11:22:53
Okay, good to know. It could just be a bug in that script.
Thanks again!, Now to try to get gtkmoniter to build, I don't know why its not building, I posted the error somwhere on DoveNet, I have all the GTK libs, etc installed but it bugs out on compile.
would it be too much to ask if you could provide binary for x64? you have a debian system right? would it cause issues? I see you have a lot of the other binarys realeased in a sbbs-dev.tgz packet. umonitor rocks, but I would love to try the gtk stuff, and it just will not compile. I don't know where I posted that message with the errors.
Re: Some questions and general comments for the Devel team.
By: KK4QBN to Digital Man on Sun Jun 04 2017 06:14 pm
Re: Some questions and general comments for the Devel team.
By: Digital Man to KK4QBN on Sun Jun 04 2017 11:22:53
Okay, good to know. It could just be a bug in that script.
Thanks again!, Now to try to get gtkmoniter to build, I don't know why its not building, I posted the error somwhere on DoveNet, I have all the GTK libs, etc installed but it bugs out on compile.
would it be too much to ask if you could provide binary for x64? you have a debian system right? would it cause issues? I see you have a lot of the other binarys realeased in a sbbs-dev.tgz packet. umonitor rocks, but I would love to try the gtk stuff, and it just will not compile. I don't know where I posted that message with the errors.
I've never tried to build Deuce's GTK stuff. I don't run X, so I would have no way to test the builds. I'll give it a shot though.
I think I might know the problem: There are no files in the directories that were not imported? If you don't import recursively and there are no files in the directories, then they won't be imported when you using the Import->Directory Listing... feature.
I could add an option to import empty directories (with no files), but why would you want that?
I've never tried to build Deuce's GTK stuff. I don't run X, so I would have no way to test the builds. I'll give it a shot though.
gtkmonitor built fine for me after I installed the GTK-devel and glade2.0 dev packages:
$ apt-get install libgtk-3-dev
$ apt-get install libglade2-dev
Re: Some questions and general comments for the Devel team.
By: Digital Man to Mro on Sun Jun 04 2017 07:52 pm
I think I might know the problem: There are no files in the directories that were not imported? If you don't import recursively and there are no files in the directories, then they won't be imported when you using the Import->Directory Listing... feature.
I could add an option to import empty directories (with no files), but why would you want that?
well maybe it would be a good idea if the sysop was adding files to that directory later.
i think you're right about this, i screwed up and i have directories inside directories in some of these.
Re: Some questions and general comments for the Devel team.
By: Digital Man to KK4QBN on Sun Jun 04 2017 11:21:43
it is in gcc.linux.x64.exe.debug under the sbl dir now that I have the
script.
Okay, and do the permissions look good (i.e. the user that the BBS runs as has read/execute permissions)?
it is in gcc.linux.x64.exe.debug under the sbl dir now that I have the
script.
Okay, and do the permissions look good (i.e. the user that the BBS
runs as has read/execute permissions)?
The problem with the 'sbl' (and other) shell scripts in the Synchronet 'xtrn' tree have now been fixed: they didn't support paths with the architecture "linux.x64" part.
elif [ -x $dirname\/gcc.$os.x64.exe.release/$exename ]elif [ -x $dirname\/*.$os.exe.release/$exename ]
then exec $dirname\/gcc.$os.x64.exe.release/$exename $@
elif [ -x $dirname\/gcc.$os.x64.exe.debug/$exename ]
then exec $dirname\/gcc.$os.x64.exe.debug/$exename $@
On 2017 Jun 10 22:36:26, you wrote to KK4QBN:
it is in gcc.linux.x64.exe.debug under the sbl dir now that I have the
script.
Okay, and do the permissions look good (i.e. the user that the BBS
runs as has read/execute permissions)?
The problem with the 'sbl' (and other) shell scripts in the Synchronet 'xtrn' tree have now been fixed: they didn't support paths with the architecture "linux.x64" part.
really? is that a regression?
max and i don't recall making any edits but
here's what her sbl shell script contains...
#!/bin/sh
os=`uname | tr "[A-Z]" "[a-z]"`
exename=`basename $0`
dirname=`dirname $0`
if [ -x $dirname\/gcc.$os.exe.release/$exename ]
then exec $dirname\/gcc.$os.exe.release/$exename $@
elif [ -x $dirname\/gcc.$os.exe.debug/$exename ]
then exec $dirname\/gcc.$os.exe.debug/$exename $@
elif [ -x $dirname\/gcc.$os.x64.exe.release/$exename ]
then exec $dirname\/gcc.$os.x64.exe.release/$exename $@
elif [ -x $dirname\/gcc.$os.x64.exe.debug/$exename ]
then exec $dirname\/gcc.$os.x64.exe.debug/$exename $@
this sbbs installation has been 64bit ever since max first compiled it... the only time we've ever had a problem was when switching between debug and release
versions but that was with the symlinks used for the other binaries of the system, IIRC...
is it better to not use SYMLINK=1 when compiling on linux?
elif [ -x $dirname\/gcc.$os.x64.exe.release/$exename ]
then exec $dirname\/gcc.$os.x64.exe.release/$exename $@
elif [ -x $dirname\/gcc.$os.x64.exe.debug/$exename ]
then exec $dirname\/gcc.$os.x64.exe.debug/$exename $@
One of you must've added those 'x64' lines. They were never in CVS.
this sbbs installation has been 64bit ever since max first compiled
it... the only time we've ever had a problem was when switching
between debug and release versions but that was with the symlinks used
for the other binaries of the system, IIRC...
is it better to not use SYMLINK=1 when compiling on linux?
I use symlinks. But the xtrn/* doors don't use the symlink method.
I use symlinks. But the xtrn/* doors don't use the symlink method.
right... that's what is done here, too... as mentioned above, the only problem we've seen with using the symlinks for the BBS binaries is when changing from release to debug or visa versa... not sure if it would be a good idea to have the make file stuff delete the file or link before copying or creating it... there would also be this problem when switching between symlink and copy, right??
But yes, when switching between release and debug, existing symlinks could point to the wrong binaries. The project makefiles (e.g. src/sbbs3/GNUmakefile) don't actually generate symlinks, so they wouldn't delete them either.
Re: Some questions and general comments for the Devel team.
By: Digital Man to mark lewis on Mon Jun 12 2017 17:32:41
But yes, when switching between release and debug, existing symlinks could point to the wrong binaries. The project makefiles (e.g. src/sbbs3/GNUmakefile) don't actually generate symlinks, so they wouldn't delete them either.
My question is. is their any other reason why one would just not copy the binaries to the root dir of whatever code they have just compiled (sbl for example).
You can do that. The build system is setup such that one system can be used to build binaries for several target platforms/architectures but they may not necessarily be native to the current system (so we don't want to start copying/overwriting executables normally).
I use symlinks. But the xtrn/* doors don't use the symlink method.
right... that's what is done here, too... as mentioned above, the
only problem we've seen with using the symlinks for the BBS binaries
is when changing from release to debug or visa versa... not sure if
it would be a good idea to have the make file stuff delete the file
or link before copying or creating it... there would also be this
problem when switching between symlink and copy, right??
I'm not sure what you mean by "this problem". The problem I was
resolving was a lack of x86_64 platform support.
But yes, when switching between release and debug, existing symlinks
could point to the wrong binaries.
The project makefiles (e.g. src/sbbs3/GNUmakefile) don't actually
generate symlinks, so they wouldn't delete them either.
On 2017 Jun 12 17:32:40, you wrote to me:
I use symlinks. But the xtrn/* doors don't use the symlink method.
right... that's what is done here, too... as mentioned above, the
only problem we've seen with using the symlinks for the BBS binaries
is when changing from release to debug or visa versa... not sure if
it would be a good idea to have the make file stuff delete the file
or link before copying or creating it... there would also be this
problem when switching between symlink and copy, right??
I'm not sure what you mean by "this problem". The problem I was resolving was a lack of x86_64 platform support.
sorry, yes, that was the original discussion... it lead me to topic drift to the problem with using symlinks when switching between DEBUG=1 and RELEASE=1 build modes and to also speculate about seeing that same problem when switching
between SYMLINK=1 mode and copy mode... that problem being that the link/file ends up being the old/previous one instead of the newly built one...
But yes, when switching between release and debug, existing symlinks could point to the wrong binaries.
oh, they certainly do... we've run into it several times ;)
The project makefiles (e.g. src/sbbs3/GNUmakefile) don't actually generate symlinks, so they wouldn't delete them either.
well, yeah, i guess but there is this section that seems to indicate that make does have something to do with it ;)
ifdef SYMLINK
INSBIN := ln -sf
else
INSBIN := cp
endif
well, yeah, i guess but there is this section that seems to indicate
that make does have something to do with it ;)
ifdef SYMLINK
INSBIN := ln -sf
else
INSBIN := cp
endif
That's in install/GNUmakefile, not src/sbbs3/GNUmakefile.
So if you just run 'make' in src/sbbs3 (as I usually do and many of
the instructions tell you to),
it's not going to symlink or copy anything (existing symlinks from
exec/* will remain of course).
| Sysop: | MCMLXXIX |
|---|---|
| Location: | Prospect, CT |
| Users: | 326 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 140:59:38 |
| Calls: | 513 |
| Messages: | 222342 |
