$ git diff sequencer.html
diff --git a/resources/sequencer.html b/resources/sequencer.html
index e7f8a79d..95c7e3d8 100644
--- a/resources/sequencer.html
+++ b/resources/sequencer.html
@@ -115,6 +115,7 @@
               <img src="icons/play.svg" title="Start" class="seqbtn Stopped" onclick="startSeq();">
               <img src="icons/debug.svg" title="Debug" class="seqbtn Stopped" onclick="debugSeq();">
               <img src="icons/square.svg" title="Stop" class="seqbtn Running Paused" onclick="stopSeq();">
+              <img src="icons/x-octagon.svg" title="Stop Run and Sequencer immediately" class="seqbtn Running Paused" onclick="stopRunAndSeq();">
               <img src="icons/pause.svg" title="Pause" class="seqbtn Running" onclick="modbset('/Sequencer/Command/Pause script',true);">
               <img src="icons/resume.svg" title="Resume" class="seqbtn Paused" onclick="modbset('/Sequencer/Command/Resume script',true);">
               <img src="icons/step-over.svg" title="Step Over" class="seqbtn Running Paused" onclick="modbset('/Sequencer/Command/Step over',true);">
[gac-megj@pc13513 resources]$ git diff sequencer.js
diff --git a/resources/sequencer.js b/resources/sequencer.js
index cc5398ef..b75c926c 100644
--- a/resources/sequencer.js
+++ b/resources/sequencer.js
@@ -1582,6 +1582,23 @@ function stopSeq() {
    });
 }

+function stopRunAndSeq() {
+   const message = `Are you sure you want to stop the run and sequence?`;
+   dlgConfirm(message,function(resp) {
+      if (resp) {
+         modbset('/Sequencer/Command/Stop immediately',true);
+
+         mjsonrpc_call("cm_transition", {"transition": "TR_STOP"}).then(function (rpc) {
+            if (rpc.result.status !== 1) {
+               throw new Error("Cannot stop run, cm_transition() status " + rpc.result.status + ", see MIDAS messages");
+            }
+         }).catch(function (error) {
+            mjsonrpc_error_alert(error);
+         });
+      }
+   });
+}
+
 // Show or hide parameters table
 function showParTable(varContainer) {
    let e = document.getElementById(varContainer);

Hello, I am a coop student working at SNOLAB. I am currently setting up a frontend 
program to collect data for an experiment I am currently having with my bank being 
initialized correctly with the correct name. I will attach an image of the error and 
a code snippet for clarity. This is a multi-thread program using ring buffers. The 
first thread  is only responsible for data collection of ADC values from the Red 
Pitaya (FPGA) and the second thread does a simple derivative calculation. The 
frontend makes use of the TCP connection to stream data from the Red Pitaya. 

Here is the code snippet. This is the only place in the frontend code where I 
initialize and create a bank to store the ADC values from the Red Pitaya. 

void* data_acquisition_thread(void* param)
{
	printf("Data acquisition thread started\n");
	// Obtain ring buffer for inter-thread data exchange
	EVENT_HEADER *pevent;
	WORD *pdata;
	int status;

	//Set a timeout for the recv function to prevent indefinite blocking
	struct timeval timeout;
	timeout.tv_sec = 10; //seconds
	timeout.tv_usec = 0; // 0 microseconds
	setsockopt(stream_sockfd, SOL_SOCKET, SO_RCVTIMEO, (char *)&timeout, 
sizeof(timeout));



	while (is_readout_thread_enabled())
	{

		if (!readout_enabled())
		{
			usleep(10); // do not produce events when run is stopped
			continue;
		}
		// Acquire a write pointer in the ring buffer
		int status;
		do {
			status = rb_get_wp(rbh, (void **) &pevent, 0);
			if (status == DB_TIMEOUT)
			{
				usleep(5);
				if (!is_readout_thread_enabled()) break;
			}
		} while (status != DB_SUCCESS);

		if (status != DB_SUCCESS) continue;

		// Lock mutex before accessing shared resources
		pthread_mutex_lock(&lock);

		// Buffer for incoming data
		//int16_t temp_buffer[4096] = {0};

		bm_compose_event_threadsafe(pevent, 1, 0, 0, 
&equipment[0].serial_number);
        pdata = (WORD *)(pevent + 1);  // Set pdata to point to the data section of 
the event

		// Initialize the bank and read data directly into the bank
        bk_init32(pevent);
        bk_create(pevent, "RPD0", TID_WORD, (void **)&pdata);

		int bytes_read = recv(stream_sockfd, pdata, max_event_size * 
sizeof(WORD), 0);
		printf("Data received: %d bytes\n", bytes_read);


		if (bytes_read <= 0)
		{
			if (bytes_read == 0)
			{
				printf("Red Pitaya disconnected\n");
				pthread_mutex_unlock(&lock);
				break;

			} else if (errno == EWOULDBLOCK || errno ==EAGAIN)
			{
				printf("Receive timeout\n");
				pthread_mutex_unlock(&lock);
				continue;
			}

			else
			{
				printf("Error reading from the Red Pitaya: %s\n", 
strerror(errno));
				pthread_mutex_unlock(&lock);
				continue;
			}

		}
		
		 // Adjust data pointers after reading
        pdata += bytes_read / sizeof(WORD);
        bk_close(pevent, pdata);

        pevent->data_size = bk_size(pevent);

		// Unlock mutex after writing to the buffer
		pthread_mutex_unlock(&lock);

		// Send event to ring buffer
		rb_increment_wp(rbh, sizeof(EVENT_HEADER) + pevent->data_size);
	}
	pthread_mutex_unlock(&lock);

	return NULL;
}

All I can see is that your bank header gets corrupted along the way. The funny character reported by 
cm_write_event_to_odb indicates that your original name "RPD0" got overwritten somewhere, but I could not spot any 
mistake in your code. 

I would play around: change max_event_size, produce dummy data of size N instead of the recv() and so on. Also monitor 
the bank header to see when it gets overwritten. I guess you only write form one thread, so that should be safe, right?

Best,
Stefan

> All I can see is that your bank header gets corrupted along the way. The funny character reported by 
> cm_write_event_to_odb indicates that your original name "RPD0" got overwritten somewhere, but I could not spot any 
> mistake in your code. 
> 
> I would play around: change max_event_size, produce dummy data of size N instead of the recv() and so on. Also monitor 
> the bank header to see when it gets overwritten. I guess you only write form one thread, so that should be safe, right?
> 
> Best,
> Stefan

Hello Stefan, 

Thank you for the advice. On inspection, I noticed that my event size (when I print bk_size(pevent)) is around 1.4 billion 
which seems absurd so I am not sure why this is the case as well. In addition, is mdump the way to monitor the bank header?
I just recently started using MIDAS so I am a little bit confused. I can attach a link to the github repository where I am 
currently working on this for further clarity since I am sure there is an issue in my code somewhere. 
(https://github.com/mgandhi-1/red-pitaya-frontend/blob/10-issue-with-bank-creation-neeed-to-figure-out-why-banks-are-not-
being-created-correctly/frontend.cxx)

I appreciate the help. Thank you once more.

Best, 
Mann

> Hello, I am a coop student working at SNOLAB.
> void* data_acquisition_thread(void* param)
> {
> 	EVENT_HEADER *pevent;
>       if (complicated) {
> 			status = rb_get_wp(rbh, (void **) &pevent, 0);
>       }
>       bm_compose_event_threadsafe(pevent, 1, 0, 0, &equipment[0].serial_number);
> }

this code is buggy. it should read "EVENT_HEADER *pevent = NULL;" to avoid an uninitialized variable
and bm_compose_event() & co should be inside an "if (pevent != NULL)" block, unless you can absolutely
proove that rb_get_wp() is always called and pevent is never NULL. (even is somebody changes the code later).

if you build your code with "gcc -O2 -g -Wall -Wuninitialized" it would probably warn you about use of uninitilialized 
"pevent".

P.S. for building multithreaded frontends, you are much better off starting from the c++ tmfe frontend framework,
a good starting point is study tmfe_example_everything.cxx.

K.O.

I have the following use case: I would like to check if two elements of an array exceed a certain threshold. 
However, they are not consecutive. Currently, I have to write two alarms, one checking Array[8] and one 
checking Array [10].

It would be nice if we could enter conditions such as "/Path/To/Array[8,10] > 0.5".

I looked into the code of al_evaluate_condition() and it seems very C-style. I know that you have been 
refactoring a lot of code to work with STL strings and their functions. If you find the time to refactor 
alarm.cxx, I ask that you consider adding comma-separated lists as a new feature.

Cheers
Lukas

These kind of alarm conditions have been implemented and committed. The documentation at 

  https://daq00.triumf.ca/MidasWiki/index.php/Alarm_System

has been updated.

/Stefan

We had the case in MEG that some alarms were actually just warnings, not very severe. This happens for example if we calibrate our detector 
once every other day and modify the hardware which actually triggers the alarm for about an hour or so.

The problem with this is now that the alarm sounds every few minutes, and people get annoyed during that hour. They turn down the volume 
of their speakers, or even disable the alarm sound. If the detector gets back into the default mode again, they might forget to re-enable the 
alarm, which causes some risk. 

Turning down the volume is also not good, since during that hour we could have a "real" alarm on which people have to react quickly in order 
not destroy the detector.

The art is now to configure the alarm system in a way that "normal" changes do not annoy people or cover up really severe alarms. After long 
discussions we came to following conclusion: We need a special class of alarm (let's call it 'warning') which does not annoy people. The 
warning should be visible on the screen, but not ring the alarm bell. 

While we have different alarm classes in midas, which let us customize the frequency of alarms and the screen colors, all alarms or warnings 
ring the alarm sound right now. This can be changed in the browser under "Config/Alarm sound" but that switch affects ALL alarms, which is 
not what we want.

The idea we came up with was to add a flag "Alarm sound" to the alarm classes. For the 'warning' we can then turn off the alarm sound, so 
only the banner is shown on top of the screen, and the spoken message is generated every 15 mins to remind people, but not to annoy them.

I added this "Alarm sound" flag in the branch feature/alarm_sound so everybody can test it. The downside is that all "Alarm/Classs/xxx" need 
to be modified to add this flag. While the new code will add this flag automatically (with a default value of 'true'), the size of the alarm class 
record changes by four bytes (one bool). Therefore, all running midas programs will complain about the changed size, until they get 
recompiled. 

Therefore, to test the new feature, you have to checkout the branch and  re-compile all midas programs you use, otherwise you will get errors 
like 

  Fixing ODB "/Alarms/Classes/Alarm" struct size mismatch (expected 352, odb size 348)

I will keep the branch for a few days for people to try it out and report any issue, and later merge it to develop.

Stefan

Another modification has been done to the alarm system. 

We have often cases where an alarm is triggered on some readout noise. Like an analog voltage just over the alarm threshold for a very short period of time, triggered sometimes from environmental 
electromagnetic effects like turning on the light. 

To mitigate this problem, an "alarm trigger count" has been implemented. Every alarm has now a variable "Trigger count required". If this value is zero (the default), the alarm system works as before. If this 
value is nowever set to a non-zero value N, the alarm limit has to be met on N consecutive periods in order to trigger the alarm. Each alarm has a "Check interval" which determines the period of the alarm 
checking. If one has for example:

Check interval = 10
Trigger count required = 3

then the alarm condition has to be met for 3 consecutive periods of 10 seconds each, or for 30 seconds in total. 

The modification has been merged into the develop branch, and people have to be aware that the alarm structures in the ODB changed. The current code tries to fix this automatically, but it is important 
that ALL MIDAS CLIENTS GET RE-COMPILED after the new code is applied. Otherwise we could have "new" clients expecting the new ODB structure, and some "old" clients expecting the old structure, 
then both types of clients would fight against each other and change the ODB structure every few seconds, leading to tons of error messages. So if you pull the current develop branch, make sure to re-
compile ALL midas clients.

/Stefan

currently to link Midas to project one has to do several steps in cmake script:
- do `find_package`
- get Midas location from MIDASSYS, or from MIDAS_LIBRARY_DIRS
- set MIDAS_INCLUDE_DIRS, MIDAS_LIBRARY_DIRS and MIDAS_LIBRARIES to your target
- add sources from Midas for mfe, drivers, etc.

in general cmake already can to all of this automatically, and the only lines you would need are:
- do `find_package(Midas ... PATHS ~/midas_install_location)`
- and do `target_link_libraries(... midas::mfe)`
  (and all include dirs, libs, and deps are propagated automatically)

see PR https://bitbucket.org/tmidas/midas/pull-requests/48
- nothing should break with current setups
- if you want to try new `midas::` targets, try to link e.g. `midas::mfed` to your frontend

After some iterations, we merged the branch with the new build scheme. Now you can compile any midas program as described at

  https://bitbucket.org/tmidas/midas/pull-requests/48?link_source=email

A default CMakeLists.txt file can look like this:

cmake_minimum_required(VERSION 3.17)
project(example)
find_package(Midas REQUIRED PATHS $ENV{MIDASSYS})
add_executable(example example.cpp)
target_link_libraries(example midas::midas)


Which is much simpler than what we had before. The trick now is that the find_package() retrieves all include and link files automatically. 
There are different targets:

midas::midas              - normal midas program
midas::midas-shared       - normal midas programs using the shared midas library
midas::mfe                - old style mfe.cxx frontend
midas::mfed               - newer style frontend using mfed.cxx
midas::mscb               - programs using MSCB system
midas::drivers            - slow control program using any of the standard midas drivers

We are not absolutely sure that all midas installations will work that way, so far we have tested it on RH8, MacOSX with cmake version 
3.29.5.

Comments and bug reports are welcome as usual.

Alex and Stefan

> ALL MIDAS CLIENTS GET RE-COMPILED after the new code is applied.

Usually we expect that it is "safe" to update to the latest version of MIDAS.

In the sense that we do not have to track down every single frontend
and rebuild it. We have several experiments where tracking down the source code
and rebuilding a frontend takes more than 5 seconds. In many cases these are
10 year old executables that worked just fine through many updates of MIDAS
without having to rebuild them.

So any binary incompatible change is best avoided and must be clearly announced.

The present binary-incompatible change is this commit:
https://bitbucket.org/tmidas/midas/commits/5899f1657ba31121c9f420a824b3c6c13b173988

I tagged the last commit before this change as: midas-2024-12-a

K.O.

> currently to link Midas to project one has to do several steps ...

this information is incorrect. please read https://daq00.triumf.ca/elog-midas/Midas/2258

a very simple way to use link MIDAS using midas-targets.cmake has been implemented a long time ago.

before proposing a new way of doing things, it would be nice to hear about shortcomings
of the existing stuff. A simple "Konstantin's way sucks" or "this is not the cmake way!"
would have been sufficient.

K.O.

> After some iterations, we merged the branch with the new build scheme.

the commit to implement this change in the manalyzer was not pushed, for reasons unknown.

fixed, commit f2b4dc87ca4830f6bed8667d6a4ee4afd6d242a1

K.O.

> > ALL MIDAS CLIENTS GET RE-COMPILED after the new code is applied.
> 
> Usually we expect that it is "safe" to update to the latest version of MIDAS.
> 
> In the sense that we do not have to track down every single frontend
> and rebuild it. We have several experiments where tracking down the source code
> and rebuilding a frontend takes more than 5 seconds. In many cases these are
> 10 year old executables that worked just fine through many updates of MIDAS
> without having to rebuild them.
> 
> So any binary incompatible change is best avoided and must be clearly announced.
> 
> The present binary-incompatible change is this commit:
> https://bitbucket.org/tmidas/midas/commits/5899f1657ba31121c9f420a824b3c6c13b173988
> 
> I tagged the last commit before this change as: midas-2024-12-a

Here are my replies:

- this is not a binary incompatibility, but a incompatibility of the /Alarm record which got two more variables. Old 
frontends will complain during their structure check and remove the two variables, new frontend will then complain as 
well and add the two variables. This will go in circles, that why all frontends need to be recompiled if the new code is 
used

- I did clearly announce this change in the forum. Is there another location where I should communicate that?

- The extension is not there "just for fun" but needed by several experiments which experience spurious alarms 
triggered by some noisy signals. Requiring an value to be above a limit for a certain minimum time fixes many issues in 
many experiments here at PSI, this is why it has been implemented, even if it causes work for everybody with re-
compilation.

- If there are frontend programs which have not been re-compiled for ten years, I think it is very unlikely that these 
experiments need the latest cutting edge version of midas. The can safely stick to your tag midas-2024-12-a and not 
experience the issue of different /Alarm trees.

Stefan

> > currently to link Midas to project one has to do several steps ...
> 
> this information is incorrect. please read https://daq00.triumf.ca/elog-midas/Midas/2258
> 
> a very simple way to use link MIDAS using midas-targets.cmake has been implemented a long time ago.

I admit that i did not see your post about targets import
via `include($ENV{MIDASSYS}/lib/midas-targets.cmake)`
before implementing changes to cmake scripts.
But in this respect the way you propose to do it via `include` should still work.
Note however that `include(...)` way is very unusual as one have to know exactly
where `...-targets.cmake` is located and standard way in cmake is via `find_package`
(similar to how e.g. ROOT, Geant4, etc. are found and linked).

The things that changed (and are incompatible with what was before)
is the naming of targets (in `midas-targets.cmake` with `midas::` namespace,
which is standard practice in cmake to distinguish cmake targets from bare library names
(e.g. when you do `link_libraries(midas)` it may be interpreted as linking with `-lmidas`
or if target is defined it does machinery to link actual cmake target; the namespace way
makes it unambiguous).
Though i again admit that maybe the namespace change was a bit too much as it may
have broken previous users of `include($ENV{MIDASSYS}/lib/midas-targets.cmake)`

> 
> before proposing a new way of doing things, it would be nice to hear about shortcomings
> of the existing stuff.

- shortcomings of what was before is usage of non-standard `include(...)`
- one shortcoming i see for new implementation is usage `midas::` namespace
  (mentioned above) that may have broken some setups

> A simple "Konstantin's way sucks" or "this is not the cmake way!"
> would have been sufficient.

- `find_package` is standard and recommended way of finding packages
    - note that `include($ENV{MIDASSYS}/lib/midas-targets.cmake)` should still work
      (but with usage of `midas::midas` instead of simply `midas`)
    - in the end `find_package` works by locating and loading `MidasConfig.cmake`,
      and it now actually does `include("${CMAKE_CURRENT_LIST_DIR}/../../midas-targets.cmake")`,
      so in this respect `find_package` is the same as `include(...)`,
      but it also preserves old behavior of exporting cmake vars for includes/libs
      such that prev uses are unaffected,
      and does a bit more checking such that it can be used for both in- and out-of-tree builds
    
- in addition `find_package` allows to handle components,
  e.g. now it is possible to do
  `find_package(Midas COMPONENTS manalyzer)`
  instead of also doing `include($ENV{MIDASSYS}/lib/manalyzer-targets.cmake)`

> 
> K.O.

Alex

> > > currently to link Midas to project one has to do several steps ...
> > this information is incorrect. please read https://daq00.triumf.ca/elog-midas/Midas/2258
> 
> I admit that i did not see your post about targets import
> via `include($ENV{MIDASSYS}/lib/midas-targets.cmake)`
> before implementing changes to cmake scripts.
>
> But in this respect the way you propose to do it via `include` should still work.
>

I proposed nothing, you did the proposing. I spent many hours trying to understand cmake (mission 
impossible!) and many more hours to implement the previously existing package scheme based
on the cmake "EXPORT" function.

> Note however that `include(...)` way is very unusual as one have to know exactly
> where `...-targets.cmake` is located and standard way in cmake is via `find_package`
> (similar to how e.g. ROOT, Geant4, etc. are found and linked).

Very difficult to cut-and-paste "include($ENV{MIDASSYS}/lib/midas-targets.cmake)".

You cannot simplify-out $ENV{MIDASSYS} because computer cannot read your mind, which of the 10 copies
of midas you want to use from which user account on which day.

Argument about "very unusual" I would buy, I am not a cmake expert and I do not know which package
finding method is in favour today.

>
> Though i again admit that maybe the namespace change was a bit too much as it may
> have broken previous users of `include($ENV{MIDASSYS}/lib/midas-targets.cmake)`
> 

I believe it did break at least one experiment, after updating MIDAS to latest version,
the analyzer would not build.

Speaking of which, did you implement your new scheme for the manalyzer so that it works
in standalone mode (without MIDAS)?

If you did not, now we have two schemes, your new scheme just for MIDAS and my old scheme
for manalyzer *and* MIDAS. xkcd 927.

> 
> - shortcomings of what was before is usage of non-standard `include(...)`
>

You should have started by posting a message spelling it out: Konstantin implemented
a scheme that uses the cmake "export" function to find midas, mfe and manalyzer,
it is very nice and works ok, but it is non-standard/obsoleted/obscure/frowned-upon/
unpopular/I-do-not-like-it/I-did-not-invent-it, and I propose implementing a new scheme
based on find_package().

>
> - one shortcoming i see for new implementation is usage `midas::` namespace
>   (mentioned above) that may have broken some setups
> 

If you think that your changes will break other people code, you should explicitely
say this in a message to this forum and hopefully provide instruction on fixing it,
i.e. in your makefile, please replace "midas" with "midas::midas".

> 
> - `find_package` is standard and recommended way of finding packages
>

Do you have a reference for this? When I look at cmake documentation, I do not see
any specific recommendation on creating packages and finding them. I do see
other people's code for finding packages and often spend hours fighting
them because said methods are designed to work only on the developer's laptop.

P.S. Did anybody ask Ben to update the MidasWiki documentation with the new find_package() information?

K.O.

> > > ALL MIDAS CLIENTS GET RE-COMPILED after the new code is applied.
>
> - I did clearly announce this change in the forum.
>

I missed the announcement and I was surprised to discover this change.

This is why I changed the title from "useful improvement" to "ACHTUNG!!!"

> - The extension is not there "just for fun" but needed by several experiments which experience spurious alarms 
> triggered by some noisy signals.

Agreed, a useful improvement.

To prevent this kind of trouble in the future, I think I should finish my crusade against db_get_record().

> - If there are frontend programs which have not been re-compiled for ten years, I think it is very unlikely that these 
> experiments need the latest cutting edge version of midas. The can safely stick to your tag midas-2024-12-a and not 
> experience the issue of different /Alarm trees.

Yes, now that I added the tag, posted a more visible notice and people who have to run frontends build against older midas 
(because reasons) can breathe out.

Also please note that "Konstantin != all experiments at TRIUMF".

K.O.

> > > > currently to link Midas to project one has to do several steps ...
> > > this information is incorrect. please read https://daq00.triumf.ca/elog-midas/Midas/2258
> > 
> > I admit that i did not see your post about targets import
> > via `include($ENV{MIDASSYS}/lib/midas-targets.cmake)`
> > before implementing changes to cmake scripts.
> >
> > But in this respect the way you propose to do it via `include` should still work.
> >
> 
> I proposed nothing, you did the proposing. I spent many hours trying to understand cmake (mission 
> impossible!) and many more hours to implement the previously existing package scheme based
> on the cmake "EXPORT" function.
I agree that cmake is difficult, especially when it comes to creating cmake scripts for library
that should work for other people (as opposed to just using other libraries).
But that is why we should try to follow recommended way of using it.

> 
> > Note however that `include(...)` way is very unusual as one have to know exactly
> > where `...-targets.cmake` is located and standard way in cmake is via `find_package`
> > (similar to how e.g. ROOT, Geant4, etc. are found and linked).
> 
> Very difficult to cut-and-paste "include($ENV{MIDASSYS}/lib/midas-targets.cmake)".
> 
> You cannot simplify-out $ENV{MIDASSYS} because computer cannot read your mind, which of the 10 copies
> of midas you want to use from which user account on which day.
One can use `find_package(Midas PATH $ENV{MIDASSYS})` to set specific location of Midas
(this is mentioned in https://bitbucket.org/tmidas/midas/pull-requests/48)
and without `PATH` argument the default system/user locations are searched.

> 
> Argument about "very unusual" I would buy, I am not a cmake expert and I do not know which package
> finding method is in favour today.
> 
> >
> > Though i again admit that maybe the namespace change was a bit too much as it may
> > have broken previous users of `include($ENV{MIDASSYS}/lib/midas-targets.cmake)`
> > 
> 
> I believe it did break at least one experiment, after updating MIDAS to latest version,
> the analyzer would not build.
This unfortunately was not easy to avoid in this case, as both midas and manalyzer depend on each other:
midas should compile when manalyzer is enabled (as submodule)
and manalyzer should compile with midas as separate lib.
So in this case i would expect both midas and manalyzer be updated at same time to their matching versions.

> 
> Speaking of which, did you implement your new scheme for the manalyzer so that it works
> in standalone mode (without MIDAS)?
The only change on manalyzer i did was to use `find_package(Midas ...)` and `midas::midas` target
(see https://bitbucket.org/tmidas/manalyzer/commits/b219a916).
If there is interest to use same scheme in manalyzer as in Midas i can implement it.

> 
> If you did not, now we have two schemes, your new scheme just for MIDAS and my old scheme
> for manalyzer *and* MIDAS. xkcd 927.
> 
> > 
> > - shortcomings of what was before is usage of non-standard `include(...)`
> >
> 
> You should have started by posting a message spelling it out: Konstantin implemented
> a scheme that uses the cmake "export" function to find midas, mfe and manalyzer,
> it is very nice and works ok, but it is non-standard/obsoleted/obscure/frowned-upon/
> unpopular/I-do-not-like-it/I-did-not-invent-it, and I propose implementing a new scheme
> based on find_package().
As i mentioned i did not see you original post about usage of `include`
and otherwise i may have referenced it and though more about compatibility issues.

> 
> >
> > - one shortcoming i see for new implementation is usage `midas::` namespace
> >   (mentioned above) that may have broken some setups
> > 
> 
> If you think that your changes will break other people code, you should explicitely
> say this in a message to this forum and hopefully provide instruction on fixing it,
> i.e. in your makefile, please replace "midas" with "midas::midas".
In the original message to this thread i posted reference to PR
(https://bitbucket.org/tmidas/midas/pull-requests/48)
where it shows how to use `find_package` with this change.
As i did not expect the direct use of `include()` form
and assumed that manual linking was used (via specifying include/lib paths/names)
some scenarios where code for people broke were missed (not taken into account) by me.

> 
> > 
> > - `find_package` is standard and recommended way of finding packages
> >
> 
> Do you have a reference for this? When I look at cmake documentation, I do not see
> any specific recommendation on creating packages and finding them. I do see
> other people's code for finding packages and often spend hours fighting
> them because said methods are designed to work only on the developer's laptop.
see https://cmake.org/cmake/help/v3.27/guide/importing-exporting/index.html:
- about use of `find_package` see https://cmake.org/cmake/help/latest/guide/using-dependencies/index.html#guide:Using%20Dependencies%20Guide
- about double colon namespace for target see https://cmake.org/cmake/help/v3.27/guide/importing-exporting/index.html
  where it is mentioned "This convention of double-colons gives CMake a hint that the name is an IMPORTED target when it is used by downstream projects".

> 
> P.S. Did anybody ask Ben to update the MidasWiki documentation with the new find_package() information?
> 
> K.O.