* [Edbrowse-dev] Just edbrowse @ 2016-01-02 16:09 Karl Dahlke 2016-01-02 20:17 ` Geoff McLane 2016-01-03 10:48 ` Adam Thompson 0 siblings, 2 replies; 6+ messages in thread From: Karl Dahlke @ 2016-01-02 16:09 UTC (permalink / raw) To: Edbrowse-dev Boy we do some silly things for historical reasons. edbrowse-js was once a different executable, so of course had to be called something different, like edbrowse-js. But then there was one executable doing two different things, and still I called the js version edbrowse-js. Software inertia I suppose. switch on argv[0], set whichproc to 'e' or 'j', etc etc. I could symlink one to the other in unix, but not in windows. It has to be a copy, in the same bin. In fact this opens up a whole can of worms in windows. We have to copy the same exe to different names, and then there's the debug convention that sticks d somewhere in the name, not entirely sure, but there's a lot of code to try to build the pathname of edbrowse-js, or edbrowse-d-js.exe, in whatever bin, and wow! We really don't need this complexity. For the js engine, invoke edbrowse --runjs for the curl server, invoke edbrowse --runcurl and so on for as many variations as we wish, never having to change makefiles or CMakeLists.txt again. And we can throw away all that code around ebjs.c line 67, because all you have to do is run argv[0] with different arguments. If argv[1] is one of our magic strings, set whichproc appropriately and run in that mode. Perhaps magic string arguments aren't your cup of tea, but it's far better than all the build / distribution issues, and symlinks or copies of renamed images in the correct bins, and so on. Geoff is on this list now, so feel free to chime in and tell us that this is definitely the way to go. Karl Dahlke ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Edbrowse-dev] Just edbrowse 2016-01-02 16:09 [Edbrowse-dev] Just edbrowse Karl Dahlke @ 2016-01-02 20:17 ` Geoff McLane 2016-01-03 10:48 ` Adam Thompson 1 sibling, 0 replies; 6+ messages in thread From: Geoff McLane @ 2016-01-02 20:17 UTC (permalink / raw) To: Karl Dahlke; +Cc: Edbrowse-dev [-- Attachment #1: Type: text/plain, Size: 1804 bytes --] Hi Karl, Yes, am now getting the dev mail ;=)) thanks... Well, as you point out the windows suffix of .EXE, and the fact that each configuration built will be in a different sub-folder, Release, Debug, etc,... and that can be Bin\Release, depending on some cmake options... **AND** the debug convention that appends a 'd' to the name, so that would be edbrowse-jsd.exe... all make it difficult to copy a binary by name to another name... It can be done, is done, but lots of cmake code to get it right... messy... And while I am aware that the binary name, argv[0], is sometimes used in unix to switch internal functionality, that is never used in Windows... Well, some die-hard unix guru, pushed to build in windows, might do it, to sort of keep the unix look/feel, that [s]he just can not live without... but that would be quite unique to WIN32... It is of course quite common to have command line options that signals entirely changed modes, like your testsock, with l=listen, c=connect, ... like say 7z, which has a,b,d,e,l,t,u,x, signalling quite different functions... And less common would be to supply say batch files to handle the difference, like say a 'edbrowse-js.bat' that then ran 'edbrowse --runjs', but many windows user, like me, write those for themselves, and do not expect them in a distribution... like I could write a runjs.bat that did the above if it was something I frequently needed... And I think I would be quite SURPRISED if what I know, can see is exactly the same binary - ( edbrowse.exe === edbrowse-js.exe ) - ran differently!!! Of course, as a developer/programmer I would correctly guess that it was using using argv[0] switching... but being the SAME binary I would expect the same action... But as always, just a windows kids perspective ;=)) Regards, Geoff. [-- Attachment #2: Type: text/html, Size: 2357 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Edbrowse-dev] Just edbrowse 2016-01-02 16:09 [Edbrowse-dev] Just edbrowse Karl Dahlke 2016-01-02 20:17 ` Geoff McLane @ 2016-01-03 10:48 ` Adam Thompson 2016-01-03 15:52 ` Karl Dahlke 1 sibling, 1 reply; 6+ messages in thread From: Adam Thompson @ 2016-01-03 10:48 UTC (permalink / raw) To: Karl Dahlke; +Cc: Edbrowse-dev [-- Attachment #1: Type: text/plain, Size: 1174 bytes --] On Sat, Jan 02, 2016 at 11:09:30AM -0500, Karl Dahlke wrote: > For the js engine, invoke > edbrowse --runjs > for the curl server, invoke > edbrowse --runcurl > and so on for as many variations as we wish, never having to change makefiles > or CMakeLists.txt again. > And we can throw away all that code around ebjs.c line 67, > because all you have to do is run argv[0] with different arguments. Makes sense. > If argv[1] is one of our magic strings, set whichproc appropriately > and run in that mode. > > Perhaps magic string arguments aren't your cup of tea, > but it's far better than all the build / distribution issues, and symlinks or copies > of renamed images in the correct bins, and so on. > Geoff is on this list now, so feel free to chime in and tell us > that this is definitely the way to go. I think I'd probably have a --mode js option, but that's because I've been thinking it'd also be nice to have a few other options like --config <config_file> to override the default .ebrc. Tbh though, --runjs, --runcurl etc don't bother me that much. It certainly beats the multiple copies of the same binary option. Cheers, Adam. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 473 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* [Edbrowse-dev] Just edbrowse 2016-01-03 10:48 ` Adam Thompson @ 2016-01-03 15:52 ` Karl Dahlke 2016-01-03 17:56 ` Geoff McLane 0 siblings, 1 reply; 6+ messages in thread From: Karl Dahlke @ 2016-01-03 15:52 UTC (permalink / raw) To: Edbrowse-dev It is done. Pull, build, edbrowse jsrt, browse, ps -u Note the arguments on the two instances of edbrowse. Adam this is your --mode idea which I like. makefiles and CMakeLists are adjusted. Geoff you might want to build / run on windows to check my work. I got rid of the path mangling software that we needed before. Looking ahead, perhaps --mode curl sets whichproc = 'c' and runs curl_main(). Karl Dahlke ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Edbrowse-dev] Just edbrowse 2016-01-03 15:52 ` Karl Dahlke @ 2016-01-03 17:56 ` Geoff McLane 2016-01-03 19:12 ` Karl Dahlke 0 siblings, 1 reply; 6+ messages in thread From: Geoff McLane @ 2016-01-03 17:56 UTC (permalink / raw) To: Karl Dahlke; +Cc: Edbrowse-dev [-- Attachment #1: Type: text/plain, Size: 3049 bytes --] Hi Karl, Pulled, built and ran what I remember of the tests... obviously did not understand your 'ps -u'... but it seemed to run fine.. ...\edbrowse\build>run-exe ..\src\jsrt ...\edbrowse\build>release\edbrowse.exe ..\src\jsrt no ssl certificate file specified; secure connections cannot be verified 21629 b doc loader attached body loading form questionnaire loading 644 30 seconds have passed! rr line 20 has been updated ps -u ? q no file q === Re: DLL (shared) Library work-around You will note how I do this with a batch file... That is because I presently link with a libcurl.dll... so I have to adjust the PATH with like - @set PATH=..\..\software\bin;%PATH% before running edbrowse... ugly, but workable... It will be in cmake, somewhere in distributed FindCURL.cmake... they usually default to finding the unix shared library, which is not so convenient in windows... The library list in my F:\Projects\software\lib is - static - libcurl.lib and libcurld.lib shared - libcurl_imp.lib and libcurld_imp.lib and the CURL find finds the 'imp' first, the import library, that uses libcurl[d].dll... hmmmm... Yes, UGH!, their chosen search order is - libcurl_imp curllib_static libcurl So the only way around this is to import the distributed FindCURL.cmake into source, put it in CMakeModules, adjust line include(${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake) to just include(FindPackageHandleStandardArgs) and make the search order - libcurl curllib_static libcurl_imp This should also work in the unix, since the shared would probably also be libcurl, the preferred there, and it would NOT have a libcurl_imp windows concoction anyway... Other cmake search packages do this better like FindPNG.cmake. They APPEND the names to search to a list, like - list(APPEND PNG_NAMES png libpng) That means I, as the user, just have to add -DPNG_NAMES=libpng16_static to my first cmake line, and I get the static library I want... well even there they messed up with the debug version, so usually end up importing it, fixing, and adding -DPNG_NAMES_DEBUG=libpng16_staticd... Anyway, will find time to test this, so I do not need that PATH setting... And if you give me more things to try with edbrowse, will try them, but be very explicit in the instructions ;=)) But it compiles and runs... === Re: library and executable(s) Of course, now that you are going with /ONE/ app, there is no real need for building the static edbr-lib separately. You may remember I started that because we had two apps that shared sources... so was more convenient for searching in the IDE... things are not artificially found twice in whole project searches... etc... So now you could - (a) put all sources directly into edbrowse, no lib, or (b) conversely put all sources in the edbr-lib, and reduce edbrowse to just main.c, a single source... I guess I would opt for the latter, but not sure why... it is all the same to the compiler, linker... and builds the same thing... an executable... Regards, Geoff. [-- Attachment #2: Type: text/html, Size: 4250 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* [Edbrowse-dev] Just edbrowse 2016-01-03 17:56 ` Geoff McLane @ 2016-01-03 19:12 ` Karl Dahlke 0 siblings, 0 replies; 6+ messages in thread From: Karl Dahlke @ 2016-01-03 19:12 UTC (permalink / raw) To: Edbrowse-dev > So now you could - > (a) put all sources directly into edbrowse, no lib, or > (b) conversely put all sources in the edbr-lib, and reduce edbrowse > to just main.c, a single source... Well the latter seems like extra steps, and I would opt for the former and ditch the library. With curl coming, and others, I think we're going to stay on the one image track, rather than who knows how many different images, so I'd say get rid of edbr-lib. Karl Dahlke ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-01-03 19:11 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-01-02 16:09 [Edbrowse-dev] Just edbrowse Karl Dahlke 2016-01-02 20:17 ` Geoff McLane 2016-01-03 10:48 ` Adam Thompson 2016-01-03 15:52 ` Karl Dahlke 2016-01-03 17:56 ` Geoff McLane 2016-01-03 19:12 ` Karl Dahlke
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).