[Edbrowse-dev] Just edbrowse

[Edbrowse-dev] Just edbrowse

[Karl Dahlke]

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

Re: [Edbrowse-dev] Just edbrowse

[Geoff McLane]

[-- 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 --]

Re: [Edbrowse-dev] Just edbrowse

[Adam Thompson]

[-- 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 --]

[Edbrowse-dev] Just edbrowse

[Karl Dahlke]

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

Re: [Edbrowse-dev] Just edbrowse

[Geoff McLane]

[-- 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 --]

[Edbrowse-dev] Just edbrowse

[Karl Dahlke]

> 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