1. Forum
  2. Usenet
  3. COMP.LANG.XHARBOUR

  • Re: Implicit starting function MAIN

    From Enrico Maria Giordano@21:1/5 to All on Wed Jan 10 11:06:56 2024
    Il 10/01/2024 11:01, Enrico Maria Giordano ha scritto:

    I noticed that in Harbour the function MAIN is the implicit starting
    function by default. Can we do the same for xHarbour?

    I forgot to mention one important thing: MAIN is already the implicit
    starting function if it is in the first linked module but not if it is
    in one of the other modules.

    --
    Enrico Maria Giordano

    http://www.emagsoftware.it
    http://www.emagsoftware.it/emgmusic
    http://www.emagsoftware.it/spectrum
    http://www.emagsoftware.it/tbosg

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Enrico Maria Giordano@21:1/5 to All on Wed Jan 10 11:01:59 2024
    I noticed that in Harbour the function MAIN is the implicit starting
    function by default. Can we do the same for xHarbour?

    --
    Enrico Maria Giordano

    http://www.emagsoftware.it
    http://www.emagsoftware.it/emgmusic
    http://www.emagsoftware.it/spectrum
    http://www.emagsoftware.it/tbosg

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ron Pinkas@21:1/5 to Enrico Maria Giordano on Wed Jan 10 11:22:55 2024
    Enrico Maria Giordano wrote:

    I noticed that in Harbour the function MAIN is the implicit starting
    function by default. Can we do the same for xHarbour?


    I am shocked. This REALLY breaks Clipper compatability!

    They refused so many of my contributions that did not break comptabilily
    like adding an extra argument to aDel() or supporting negative argument
    for SubStr(), with the excuse that it would "BREAK Clipper ERROR
    COMPATABILITY" :)

    Anyway I do not see any reason to make such change.

    Ron

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Enrico Maria Giordano@21:1/5 to All on Wed Jan 10 19:10:26 2024
    Il 10/01/2024 17:22, Ron Pinkas ha scritto:

    I noticed that in Harbour the function MAIN is the implicit starting
    function by default. Can we do the same for xHarbour?

    I am shocked. This REALLY breaks Clipper compatability!

    They refused so many of my contributions that did not break comptabilily
    like adding an extra argument to aDel() or supporting negative argument
    for SubStr(), with the excuse that it would "BREAK Clipper ERROR COMPATABILITY" :)

    Anyway I do not see any reason to make such change.

    I see one: many compilers (at least MSC and BCC CLANG) allow parallel compilation of multiple modules. This speed up the compilation a lot,
    but the order of the modules is unpredictable so the MAIN function could
    not be in the first linked module. But don't worry, there are other ways
    to achieve the same, no problem. Anyway, who cares of Clipper
    compatibility nowadays?

    --
    Enrico Maria Giordano

    http://www.emagsoftware.it
    http://www.emagsoftware.it/emgmusic
    http://www.emagsoftware.it/spectrum
    http://www.emagsoftware.it/tbosg

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ron Pinkas@21:1/5 to Enrico Maria Giordano on Wed Jan 10 15:55:46 2024
    Enrico Maria Giordano wrote:


    Il 10/01/2024 17:22, Ron Pinkas ha scritto:

    I noticed that in Harbour the function MAIN is the implicit starting function by default. Can we do the same for xHarbour?

    I am shocked. This REALLY breaks Clipper compatability!

    They refused so many of my contributions that did not break comptabilily like adding an extra argument to aDel() or supporting negative argument
    for SubStr(), with the excuse that it would "BREAK Clipper ERROR COMPATABILITY" :)

    Anyway I do not see any reason to make such change.

    I see one: many compilers (at least MSC and BCC CLANG) allow parallel compilation of multiple modules. This speed up the compilation a lot,
    but the order of the modules is unpredictable so the MAIN function could
    not be in the first linked module. But don't worry, there are other ways
    to achieve the same, no problem. Anyway, who cares of Clipper
    compatibility nowadays?


    I think compiling can be paralel but link is one command with explicit
    order running afer all compiler threads ended.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Enrico Maria Giordano@21:1/5 to All on Wed Jan 10 23:13:52 2024
    Il 10/01/2024 21:55, Ron Pinkas ha scritto:

    I think compiling can be paralel but link is one command with explicit
    order running afer all compiler threads ended.

    Yes, but you will need an explicit list of the modules. I would prefer
    to use *.obj instead.

    --
    Enrico Maria Giordano

    http://www.emagsoftware.it
    http://www.emagsoftware.it/emgmusic
    http://www.emagsoftware.it/spectrum
    http://www.emagsoftware.it/tbosg

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ron Pinkas@21:1/5 to Enrico Maria Giordano on Wed Jan 10 23:08:38 2024
    Enrico Maria Giordano wrote:


    Il 10/01/2024 21:55, Ron Pinkas ha scritto:

    I think compiling can be paralel but link is one command with explicit order running afer all compiler threads ended.

    Yes, but you will need an explicit list of the modules. I would prefer
    to use *.obj instead.


    I would strongly discourage such practice.

    1. We already have proper explicit single link command per executable.
    2. If/when paralel compilation is configured many targets can be built
    in paaralel and *.obj is dangerous (even without multiple targets)
    3. Many link command use C startup module which must be first
    4. Many librarries/linker combos require --start-group --end-group

    I do understand you might mean only in context of prgs only project
    but I would still insistt it is dangerous.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Enrico Maria Giordano@21:1/5 to All on Thu Jan 11 10:32:43 2024
    Il 11/01/2024 05:08, Ron Pinkas ha scritto:

    Yes, but you will need an explicit list of the modules. I would prefer
    to use *.obj instead.

    I would strongly discourage such practice.

    Sorry, but I'm using it for my work and it is working perfectly.

    --
    Enrico Maria Giordano

    http://www.emagsoftware.it
    http://www.emagsoftware.it/emgmusic
    http://www.emagsoftware.it/spectrum
    http://www.emagsoftware.it/tbosg

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ron Pinkas@21:1/5 to Enrico Maria Giordano on Thu Jan 11 10:46:47 2024
    Enrico Maria Giordano wrote:


    Il 11/01/2024 05:08, Ron Pinkas ha scritto:

    Yes, but you will need an explicit list of the modules. I would prefer
    to use *.obj instead.

    I would strongly discourage such practice.

    Sorry, but I'm using it for my work and it is working perfectly.


    Clipper, Harbour, and xHarbour allready have such feature - you just need
    to name your startup procedure _AppMain().

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Enrico Maria Giordano@21:1/5 to All on Thu Jan 11 18:54:35 2024
    Il 11/01/2024 16:46, Ron Pinkas ha scritto:

    Clipper, Harbour, and xHarbour allready have such feature - you just need
    to name your startup procedure _AppMain().

    Great, works perfectly, thank you! :-)

    --
    Enrico Maria Giordano

    http://www.emagsoftware.it
    http://www.emagsoftware.it/emgmusic
    http://www.emagsoftware.it/spectrum
    http://www.emagsoftware.it/tbosg

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)